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ABSTRACT 

•The  purpose  of  this  thesis  was  to  determine  the  feasibilty 
of  incorporating  a  Sun  Workstation  into  a  Command  and  Control 
station  to  aid  players  in  the  execution  of  their  roles  in  the 
Joint  Theater  Level  Simulation.  This  entailed  reviewing  the 
possibility  of  eliminating  the  Postprocessor  from  the 
analysis  phase  of  the  game  play.  The  Joint  Theater  Level 
Simulation  is  a  theater  independent  computer  game  that  models 
two-sided  air,  ground  and  naval  combat,  utilized  for  warfare 
training,  joint  operational  and  planning  and  doctrinal 
analysis.  The  products  of  this  thesis  will  interface  the  Sun 
Workstation  with  the  wargame's  host  computer,  the  VAX-11,  to 
provide  the  players  the  capability  to  access  and  analyze  game 
data  to  improve  their  decision  maaking  ability.  To  meet  this 
end,  several  software  products  were  produced  which 
specifically  interfaced  with  the  VAX-11,  Sun  Workstation  and 
Ethernet.  ’  • 
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I .  INTRODUCTION 


A.  WAR  GAMING 

Of  paramount  importance  in  any  combat  situation  is  the 
ability  of  a  commander  to  manage  his  forces  and  weapons 
effectively.  For  the  commander  to  be  able  to  execute  his 
role  in  the  management  of  these  assets,  he  must  be  able  to 
continually  assess  his  own  situation,  and  formulate  his 
intentions  relative  to  the  most  current  data  available  to  him 
at  that  instant  in  time. 

For  many  years  models,  simulations  and  games  have  been 
commonly  incorporated  as  analytical  tools  to  aid  those  in  the 
"war  fighting"  business.  Not  surprisingly,  within  the  last 
fifteen  years  there  has  been  a  renewed  interest  in  the  area 
of  wargaming  by  the  Department  of  Defense  (DOD)  as  more 
powerful,  reliable  and  reasonably  priced  computer  systems 
have  been  made  available  [Ref.l].  A  role  for  computers  in 
battle  analysis  has  perhaps  finally  found  its  niche  within 
the  military  wargaming  community.  At  all  levels  throughout 
the  Department  of  Defense,  emphasis  is  being  placed  on 
wargaming  as  a  very  important  training  and  analytical  tool 
[Ref  2]  .  Up  to  now  the  emphasis  has  been  placed  on  major 
force  and  theater  level  applications.  This  drive  is 
currently  being  headed  by  the  Joint  Chiefs'  of  Staff  Modern 
Aids  to  Planning  Program  (MAPP),  which  now  provides  the 
commanders  in  chief  with  powerful  data  processing 
capabilities  for  evaluating  military  alternatives  in 
appropriate  situations  [Ref.  3) . 

B.  PURPOSE 

One  of  those  theater-level  applications  is  the  Joint 
Theater  Level  Simulation  (JTLS) .  Though  the  game  is  valid 
as  a  simulation  of  theater  level  combat  activities,  in  its 
current  configuration,  it  has  a  major  distraction  which 
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prevents  maximum  exploitation  of  the  training  that  it  offers. 
Presently,  real-time  analysis  of  game-generated  data  cannot 
be  conducted  while  the  game  is  being  played.  Instead,  either 
the  game  must  be  temporarily  halted  and  saved  for  later 
restart,  or  the  game  must  be  completely  terminated  [Ref  4]  . 
Then  a  Postprocessor  must  be  loaded  and  invoked  through  a 
sequence  of  time  consuming  steps  by  one  of  the  controllers 
or  players.  This  procedure  requires  the  players  of  JTLS  to 
learn  more  than  just  how  to  play  the  game.  The  players  are 
now  compelled  to  also  learn  how  to  make  use  of  the 
Postprocessor  in  order  to  complete  the  analysis  and  critique 
phase  of  the  gaming  process.  The  players  must  therefore, 
endure  both  the  disruption  o:  stopping  the  game  and  the 
inconvenience  of  learning  how  to  use  another  piece  of 
software . 

This  block  of  action  is  extraneous,  cumbersome, 
inefficient  and  greatly  distracts  from  the  play  of  the  game. 
We  propose  that  the  Postprocessor  be  eliminated  altogether 
from  this  war-gaming  system.  In  its  place  an  alternative 
process  needs  to  be  developed  that  will  allow  the 
game-generated  data  to  be  sent  directly  to  a  database 
management  system  facilitating  immediate  use  of  the  data  by 
the  player  for  on-line  summary  of  current  situational  status. 

To  preclude  the  need  to  continually  run  the  large  and 
cumbersome  simulation  to  test  the  feasibility  of  this 
proposal,  a  major  portion  of  the  research  of  the  thesis  will 
be  devoted  to  the  formulation,  testing  and  implementation  of 
the  Push,  Pull,  and  Pack  programs.  The  corollary  goals  will 
be : 

1)  to  have  the  data  sent  through  the  network  by  the  Push 

frogram  to  be  accepted  on  the  Sun  Workstation  by  the 
ull  program, 

2)  to  populate  an  ORACLE  database  with  the  data  accepted 
by  the  Pull  program  via  the  Pack  program, 

3)  to  ensure  that  consistency  exists  between  the  data 
generated  by  the  game  with  respect  to  the  data  now 
available  in  the  ORACLE  DBMS,  and 


4)  to  execute  several  SQL*C  formulated  queries  to 
demonstrate  that  there  has  been  no  additional 
operational  restrictions  placed  on  the  game  play 
because  of  the  displacement  of  the  Postprocessor. 


In  order  to  implement  the  proposal,  we  submit  that  Sun 
Workstations,  which  are  now  available  in  the  Naval 
Postgraduate  School  war  laboratory,  be  incorporated  into  the 
currently  configured  local  area  network.  The  result  of  this 
modification  will  facilitate  the  game  data  being  directly 
placed  into  the  ORACLE  DBMS.  To  complete  the  feasibility 
testing,  a  single  Sun  Workstation  installed  with  the  ORACLE 
DBMS  will  be  dedicated  to  the  querying  of  the  database  to 
provide  this  real-time  game  analysis.  The  actual  number  of 
Sun  Workstations  will  have  no  imact  on  the  present  gaming 
configuration  nor  will  it  impact  the  development  and 
implementation  of  the  Push  program. 

The  proposed  changes,  if  successfully  incorporated,  can 
only  enhance  the  effectiveness  of  the  game.  The  ability  to 
do  real-time/on-line  analysis  of  the  game  cannot  help  but 
promote  a  greater  sense  of  realism  in  the  simulation  game. 
Subsequently,  this  will  significantly  contribute  to  making 
the  whole  realm  of  simulation  gaming  a  more  viable 
evaluation  source  of  the  decision-making  process  during 
times  of  stress  and  uncertainty.  This  change  will  provide  a 
close  replication  of  the  demands  placed  on  a  decision  maker 
during  . ircumstances  that  cannot  or  are  not  desirable  to  be 
recreated  in  the  real  world. 


C.  THESIS  OUTLINE 


It  is  the  purpose  of  this  thesis  to  review  the  current 
implementation  of  the  JTLS  system  and  to  test  the  feasibility 
of  incorporating  a  relational  database  management  system 
directly  into  the  playing  phase  of  the  game.  In  order  to 
accomplish  this,  the  thesis  was  partitioned  into  several 
chapters,  each  dealing  with  specific  aspects  of  the  current 
JTLS  implementation  to  include  both  its  software  and 


hardware  architectures . 
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Following  this  introductory  chapter.  Chapter  2  is 
dedicated  to  the  analysis  of  the  actual  project.  The 
physical  and  temporal  constraints  of  this  project  are 
enumerated.  Detailed  explanations  to  support  various  design 
decisions  are  presented  to  justify  the  options  selected. 

The  third  chapter  includes  a  very  simple  description  of 
the  JTLS  game.  Postprocessor  and  the  essential  user 
functions  for  both.  Only  major  aspects  of  these  functions 
are  discussed  to  provide  the  reader  an  opportunity  to 
understand  the  peculiarities  of  the  game  and  the  user 
requirements  of  the  current  system. 

The  fourth  chapter  consists  of  an  indepth  description  of 
the  INGRES  DBMS,  currently  used  in  the  query  and  analysis 
phase  of  the  game  play. 

Appropriately,  the  fifth  chapter  explores  the 
characteristics  of  the  ORACLE  DBMS.  This  chapter  contains 
several  examples  of  how  specific  ORACLE  features  contribute 
to  the  flow  of  game  play. 

A  very  basic  explanation  of  a  generic  local  area  network 
(LAN)  follows  in  Chapter  6  with  much  emphasis  on  TCP/IP  and 
their  role  in  data  transmission  across  the  internet.  This 
chapter  is  included  to  familiarize  readers  with  appropriate 
terms,  concepts  and  general  implementation  of  an  abstract 
local  area  networking  system.  For  those  who  have  had 
significant  exposure  to  networking,  this  chapter  provides  a 
very  cursory  review  of  pertinent  topics  in  the  networking 
subject  area. 

The  seventh  chapter  has  been  devoted  to  the  formulation, 
elaboration,  implementation  and  analysis  of  the  several 
software  programs  which  are  required  to  interface  with  the 
internet,  the  Sun  Workstation  and  the  ORACLE  DBMS.  This 
includes  the  inception  of  the  various  programs,  flow  charts 
of  the  algorithms  and  finally,  a  detailed  narrative  of  the 
actual  execution  of  the  programs. 


Chapter  8  contains  a  brief  outline  of  how  the  Relational 
Design  was  developed,  coalescing  data  information  from 
several  unrelated  technical  manuals.  The  actual  Relational 
Design  is  available  in  Appendix  J. 

The  last  chapter  contains  conclusions  and  recommended 
areas  for  further  study. 


II.  APPROACH  TO  THE  PROBLEM 


A.  INTRODUCTION 

The  question  of  why  the  Postprocessor  was  initially 
created  must  be  answered  in  order  to  appreciate  its  role  in 
the  current  configuration  of  this  simulation.  Discussion 
with  Rolands  and  Associates  Inc.,  the  current  contractors  of 
JTLS,  reveals  that  the  CALTECH  Jet  Propulsion  Laboratory 
( JPL) ,  the  original  contractors  of  the  war  game,  wanted  JTLS 
to  be  a  distributed  war-gaming  system  that  would  work  as  fast 
and  efficiently  as  possible  [Ref.  5].  With  the  complete 
separation  of  a  database  from  the  war  game,  the  contention 
for  processor  time  on  a  single  processor  system  was  no  longer 
a  point  of  concern.  The  VAX  machine  became  a  dedicated 
machine  for  the  execution  of  the  game.  Therefore,  the 
subsequent  use  of  the  Postprocessor,  after  the  game  had  been 
stopped,  had  no  impact  on  the  execution  speed  of  the  game. 
The  tradeoff  between  a  fast  game  and  the  inconvenience  of 
periodically  stopping  the  game  while  waiting  for  the 
Postprocessor  to  read  the  many  files  to  prepare  the  INGRES 
database  was  soon  reassessed.  The  six  to  eight  hours  that 
were  required  for  the  Postprocessor  to  transfer  the  gaming 
data  for  an  eighteen  to  twenty-four  hour  play  period  became  a 
point  for  discussion,  and  a  remedy  was  sought  to  reduce  this 
wasted  time  [Ref.  6]  . 


B.  PROBLEM  CONSTRAINTS 
1.  Application 


The  basic  characteristics  of  JTLS  will  be  considered 
invariable  for  the  purpose  of  this  thesis.  The  actual 
execution  of  the  war  game  will  have  no  impact  on  the 
development  and  performance  of  the  Push,  Pull  and  Pack 
programs . 
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2 .  Language 

The  selection  of  SIMSCRIPT  II.  5  as  the  programming 
language  of  JTLS  will  not  be  changed.  Aside  from  the 
obvious  reason  of  having  to  transpose  the  entire  algorithm 
into  another  language,  a  more  difficult  task  is  the 
selection  of  a  suitable  alternative  simulation  language. 
SIMSCRIPT  II. 5  is  a  programming  language  especially 
developed  to  be  used  for  this  type  of  application  [Ref.  5]. 
Its  close  resemblance  to  FORTRAN  makes  it  a  language  of 
choice  for  many  of  the  original  programmers  of  JTLS  who  were 
already  quite  familiar  with  FORTRAN. 

SIMSCRIPT  II. 5' s  intimate  compatibility  with  VMS 
allows  the  exploitation  of  the  peculiarities  of  this 
operating  system,  resulting  in  fast  and  efficient  execution 
of  the  game  code,  of  the  system  calls  and  of  all  other  lower 
level  subroutines  that  other  wise  may  not  have  been  possible 
[Ref.  5]  .  As  is  the  claim  of  so  many  other  languages  which 
are  available  today,  SIMSCRIPT  II.  5  is  extremely  readable, 
requiring  minimum  documentation.  More  importantly,  it  is 
very  flexible,  with  provisions  for  access  to  many  features  of 
the  VMS  operating  system  which  are  not  so  readily  available 
to  other  programming  languages.  Additionally.  SIMSCRIPT 
II.  5  is  a  very  efficient  higher-level  language  with  an 
extremely  high  execution  rate  which  is  so  essential  in  a 
sequentially  read  simulation  program  attempting  to  retain  as 
close  to  a  real-time  scenario  as  possible. 

3 .  Programs 

The  Push  program  is  being  developed  to  assist  in 
testing  the  feasibility  of  reducing,  and  possibly  totally 
eliminating,  the  use  of  the  Postprocessor  from  the  playing 
sequence  in  JTLS.  This  program  accommodates  the  testing 
phase  of  this  proposal  by  simulating  the  data  handling 
activities  of  the  Combat  Events  Program  (CEP) .  Through  the 
implementation  of  the  Push  program,  the  need  to  repeatedly 
run  JTLS  as  a  data  source  to  populate  the  ORACLE  database  for 
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demonstration  purposes  is  alleviated.  After  the  termination 
of  an  initial  run  of  JTLS,  the  Push  program  will  use  the 
saved  files  that  were  generated  as  its  source  of  data  for 
later  use.  The  Push  program  must  be  able  to  extract  the 
data  from  these  several  files. 

Using  the  SEND  and  RECEIVE  interprocess  communication 
primitives  available  with  TCP/IP,  the  data  is  sent  via  the 
Ethernet  from  the  VAX  to  a  Sun  Workstation.  There  another 
set  of  programs,  called  Pull  and  Pack,  were  written  to 
accept,  parse,  and  finally  populate  the  appropriate  tables 
located  in  the  ORACLE  database.  A  hard  fast  constraint 
which  was  strictly  enforced  is  that  the  transported  data 
cannot  be  modified  from  it  inception  at  game  start  through 
the  time  it  is  presented  as  information  to  an  ORACLE  based 
query . 

The  reasons  for  the  selection  of  FORTRAN  as  the 
language  of  choice  for  the  Push,  Pull,  and  Pack  programs  are 
several.  FORTRAN  has  proven  to  be  a  very  readable  language 
and  very  easy  to  document,  which  is  indeed  a  major  advantage 
over  such  available  languages  as  C.  SIMSCRIPT  II.  5  was 
originally  considered  as  the  language  for  the  programs  to 
maintain  uniformity  and  total  compatibility  with  the  gaming 
code,  and  to  reduce  maintenance  inconveniences.  However,  it 
was  not  chosen  because  of  the  local  lack  of  availability  of 
appropriate  programming  manuals  and  the  scarcity  of  any 
experienced  point  of  consultation  when  unable  to  surmount  a 
SIMSCRIPT  II. 5  oriented  programming  hurdle.  No  other 
languages  are  currently  supported  by  the  VAX  system  in  the 
Naval  Postgraduate  School  war  laboratory. 

4 .  Database  Management  System 

The  U.S.  Army  decided  to  adopt  INGRES  as  the  Army¬ 


wide  standard  database  management  system.  In  response  to 
this  decision,  JPL  developed  the  Postprocessor  to  work  in 
conjunction  with  the  INGRES  DBMS.  Therefore,  the  INGRES  DBMS 
is  the  relational  database  that  the  Postprocessor  populates 


with  data  from  the  game  files.  INGRES  DBMS  was  the  preferred 
database  for  this  research  project.  However,  due  to  the 
limitation  of  funds,  the  war  laboratory  was  not  able  to 
procure  a  copy  of  the  INGRES  DBMS  for  our  use. 

Instead,  the  ORACLE  DBMS  was  made  available.  It  too, 
is  a  relational  DBMS  with  many  of  the  same  features  offered 
by  the  INGRES  DBMS.  Because  the  differences  between  the  two 
DBMS'  are  minimal,  the  ORACLE  translations  of  the  INGRES 
queries  were  anticipated  to  be  completed  with  minor  effort. 

5 .  Hardware 

The  selection  of  the  computer  system  cannot  be 
changed  be  cause  JTLS  was  designed  and  developed  to  be  run 
exclusively  on  the  VAX  machine.  Attempts  to  transport  this 
war  game  onto  another  computer  will  entail  a  large  effort  in 
modifying  the  original  algorithm  to  accommodate  the  software 
and  hardware  specif ications  of  the  other  system. 


C.  ANALYSIS 

1 .  Procedure 

Three  different  aspects  of  the  proposed  system  were 
thoroughly  analyzed.  First,  the  ability  of  the  Push,  Pull, 
and  Pack  programs  to  correctly  send  and  receive  the 
time-sequenced  data  were  extensively  tested.  Second,  the 
correctness  and  consistency  of  the  data  processed  by  each 
program  were  ascertained  by  simply  comparing  the  data  with 
those  in  the  game  generated  data  file.  Finally,  to  aid  in 
the  development  of  the  database  tables  and  to  ensure  the 
correctness  of  these  tables,  a  comprehensive  and  thoroughly 
documented  Semantic  Data  Model  and  Relational  Design  were 
constructed. 


Database  Population 


Currently  JTLS  is  operated  as  a  stand-alone 
simulation  with  no  dedicated  DBMS.  This  precludes  a  rigid 


and  controlled  analysis  of  the  game  situations  from  being 
performed  as  it  is  being  played.  For  such  analysis  to  take 


place,  the  game  must  be  halted  and  the  Postprocessor 


invoked.  Following  the  invocation  of  the  Postprocessor, 

the  players  must  wait  until  all  the  data  have  been  read  from 
the  69  various  game  generated  files.  The  time  it  takes  to 
transfer  the  data  is  related  to  the  amount  of  data  that  is 
available  on  the  files.  Experience  has  shown  that  for  a 
!  game  that  has  been  played  for  approximately  eighteen  hours, 

i 

the  transfer  time  is  between  six  to  eight  hours.  Following 
this  inordinate  amount  of  waiting  to  populate  the  INGRES 
i  database,  the  players  are  finally  able  to  query  their  data 

source  for  situational  summaries  and,  pertinent  battle  and 
i  logistics  reports. 

The  thrust  of  the  thesis,  as  already  outlined,  are 
manifold.  Initially  the  creation  of  the  Push,  Pull,  and  Pack 
programs  must  be  completed.  These  programs  will  lend 
credence  to  the  proposal  that  a  database  system  on  an 
internet  can  being  run  on  a  separate  computer.  The  final 
result  is  the  elimination  of  the  Postprocessor  and 
consequently,  the  availability  of  an  on-line,  real-time 
querying  capability.  Next,  a  complete  Relational  Design  for 
the  JTLS  database  must  be  developed.  The  model  must  be  used 
to  construct  the  needed  tables  to  be  populated  by  the  game. 
The  Pack  program  will  then  access  those  tables  and  populate 
them  with  the  required  data.  The  populated  database  is 
made  accessible  to  the  players  as  the  game  is  in  progress. 
The  Push  program  will  simulate  the  game  in  progress  with  the 
time-stamped  data  being  placed  into  the  Ethernet  at  the 
specified  times. 

3 .  Data  Consistency 

Expected  data  consistency  is  perhaps  the  most 
essential  part  of  this  entire  project.  Without  the  proper 
transfer  of  data,  the  entire  feasibility  test  fails 
regardless  of  whatever  else  has  been  accomplished .  Although 
the  Postprocessor  is  cumbersome  and  time  intensive  to  use, 
information  is  nevertheless  being  generated.  Should  the 
Push  program  fail  to  transfer  consistent  data,  then  less 
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information  is  made  available  to  the  game  players.  No 
deviation  from  what  the  game  generates  can  be  tolerated. 

Several  runs  were  be  conducted  to  help  generate  a 
consistent  set  of  data  for  analytical  purposes.  It  is 
assumed  that  the  network  is  reliable  [Ref.  9]. 


III.  JOINT  THEATER  LEVEL  SIMULATION 


A.  INTRODUCTION 

For  the  purposes  of  this  thesis  a  complete  description 
of  the  user  interfaces  or  the  application  program 

characteristics  will  not  be  included.  Literature  to  that 
effect  is  already  available  in  such  publications  as 
Postprocessor  User  Guide  [Ref.  4],  and  JTLS  Executive 
Overview  [Ref.  5].  Instead,  only  those  minimal  features 
which  contribute  to  the  reader's  appreciation  of  the 
complexity  of  a  simulation  game  will  be  presented. 

B.  JOINT  THEATER  LEVEL  SIMULATION  OVERVIEW 

The  JTLS  is  a  computer-assisted  wargaming  system  that 
models  two-sided  air,  ground  and  naval  combat.  The  system 
runs  on  Digital  Equipment  Corporation  VAX  minicomputers,  to 
include  the  11/780,  11/785,  and  8600  [Ref.  5] . 

The  noteworthy  points  that  set  JTLS  apart  from  almost 
all  other  wargaming  models  become  evident  after  noting  the 
enormous  effort  placed  in  the  design  and  development  of  an 
efficient  and  effective  total  system.  These  considerations 
are  outlined  below: 

1)  The  primary  software  language,  SIMSCRIPT  II. 5,  was  de 
signed  for  creating  simulations. 

2)  The  user-machine  interaction  permits  inputs  and 
outputs  to  be  available  at  independent  dummy 
terminals. 

3)  A  message-handling  system  and  screen  menuing 
capability  is  provided  to  the  user. 

4)  An  expandable  memory  capacity  allows  increased 
database  requirements  to  be  accommodated  [Ref  4]. 

5)  The  design  facilitates  future  product  improvements. 

6)  Configuration  management  procedures  provide  for 
ongoing  visibility  and  control  of  software  and 
documentation . 

7)  A  rather  important  user  feature  is  the  capability  to 
run  the  game  faster  or  slower  than  real-time.  During 
large  scale  battle  problems,  a  great  deal  of  time  may 
be  spent  searching  for  the  opponent's  forces, preparing 
to  receive  logistics,  preparing  positions,  etc.  If 


the  problem  were  to  run  at  real-time,  the  participants 
may  spend  many  hours  waiting  for  the  enemy  to  be 
detected.  By  allowing  the  game  to  run  faster  than 
real-time  it  is  possible  to  shorten  the  detection 

Ehase  of  the  problem.  Once  the  actual  conflict 
egins,  the  warfare  simulation  can  be  run  at  real-time 
speed  or  slower. 

8)  Possibly  the  most  impressive  feature  of  JTLS  is  that 
the  game  runs  as  close  to  real-time  as  is  possible  in 
a  program  that  is  sequentially  executed.  This  means 
that  the  user  has  the  same  amount  of  time  to  act  or 
react  to  tactical  situations  as  he  would  in  real 
conflicts.  It  is  this  feature  that  makes  JTLS  such  an 
effective  training  tool.  This  powerful  feature  will  be 
carried  further  by  the  added  ability  to  analyze  the 
game  in  real-time.  The  ability  to  query  the  database 
to  determine  what  is  happening  at  any  particular 
moment  enhances  the  sense  of  realism.  Of  course  due 
to  the  "fog  of  battle",  not  all  information  should  be 
readily  available  to  the  players .  However,  this  lack 
of  information  or  misinformation  will  be  deliberately 
programmed  into  the  game  algorithm,  further  simulating 
the  "heat  of  battle". 

1 .  Current  Configuration 

The  current  JTLS  system  is  a  sequentially  executed, 
user  interactive,  event-driven  simulation.  In  a  future 
version  of  JTLS,  it  has  the  potential  of  becoming  a 
distributed  war-gaming  system.  However  for  now,  the  system 
software  is  executed  on  a  single,  central  stand-alone  VAX 
computer.  All  the  executive  functions  are  thus  performed  on 
that  single  computer. 

In  this  configuration  the  JTLS  executive  functions 
are  divided  into  two  main  groups.  These  function  are  the 
user  interfaces  and  the  execution  of  the  simulation  game. 
The  user  interface  function  is  performed  through  the  Model 
Interface  Program  (MIP) .  To  activate  each  user's  MIP,  the 
player  must  go  through  a  login  procedure  at  the  start  of 
game  play.  These  terminals  are  the  only  means  by  which  a 
player  will  make  his  input  available  to  the  game. 

JTLS  can  currently  support  a  maximum  of  28 
workstations/terminals  and  10  graphic  screens  [Ref.  5].  Two 
of  the  terminals  are  used  by  the  technical  coordinator  whose 
responsibilities  include: 

1)  start-up  of  the  graphic  processor, 

2)  control  of  the  Postprocessor  program, 

3)  start-up  of  the  CEP,  and 


4)  saving  the  output  from  the  execution  of  the  CEP. 

At  least  one  terminal  will  be  made  available  to  the 
game  controller.  In  this  capacity,  the  individual  will 

1)  be, able  to  modify  the  data  parameters  in  the 
initial  database, 

2)  be  able  to  modify  the  logistics  for  any  player  in 
the  game,  and 

3)  be  able  to  control  the  movement  of  the  units  in 
the  game . 

To  manage  the  simulation  of  the  commander's  role  and 
decision  making  process  in  actual  combat,  the  Blue  Commander 
and  the  Red  Commander  will  each  be  assigned  one  terminal. 
From  his  respective  terminal  each  commander  has  the  ability 
to  observe  the  graphics  screen,  hold  staff  meetings,  request 
reports  and  dictate  guidance.  The  remaining  23  terminals  may 
be  used  by  supplementary  game  controllers  (if  required), 
additional  Commanders,  Air  players.  Intelligence  players  or 
Logistics  players  [Ref.  5].  In  addition  to  the  textual 
information  available  on  the  terminal  screens,  each  of  the 
available  graphic  screens  may  be  assigned  to  one  or  more 
players  of  the  same  side.  The  minimum  configuration  for 
game  execution  consists  of  at  least  four  workstations.  There 
is  one  station  dedicated  to  the  Red  Commander,  one  station  to 
the  Blue  Commander,  one  station  to  the  game  controller,  and 
one  station  to  the  technical  coordinator  [Ref.  5], 

2 .  The  Model  Interface  Program 

JTLS  receives  user  commands  through  the  MIP .  The 
MIP  is  an  interactive  program  called  by  each  of  the  players 
located  at  an  active  terminal.  A  player  MIP  provides 
continuous  interaction  between  the  CEP  and  the  player. 

The  MIP  provides  the  users  with  the  following 
capabilities : 

1)  entering  orders; 

2)  processing  orders; 

3)  communicating  between  players  and  controllers; 

4)  communicating  between  players  and  the  combat 
simulation; 


5)  accessing  and  using  support  information; 

6)  saving  directives  in  archive  files; 

7)  analyzing  Postprocessor  data; 

8)  controlling  graphics  output;  and 

9)  stopping  or  temporarily  halting  the  game. 

The  number  of  stations  and  MIPs  needed  is  a  user 
variable,  and  is  dependent  upon  the  exercise  or  the  system 
application.  Through  the  MIP  each  player  is  able  to 

transmit  his  decisions,  in  the  form  of  orders,  to  the  CEP. 


The  CEP  is  the  warfare-simulation  model  around  which 


JTLS  is  developed.  The  modules  included  in  the  CEP  simulate 
the  movement  and  interaction  of  land,  air  and  sea  forces  for 
the  two-sided  combat. 


C.  POSTPROCESSOR 


The  JTLS  Postprocessor  is  a  tool  that  is  used  to 
generate  information  for  wargame  analysis.  The  primary 
software  tool  used  by  the  Postprocessor  is  the  Interactive 
Graphics  and  Retrieval  System  (INGRES) ,  a  commercial 
relational  database  management  system  produced  by  Relational 
Technology,  Inc.  INGRES  is  augmented  by  a  menu  system  for 
ease  of  use  and  a  separate  user-controller  data  recording 
and  assimilation  mechanism.  The  Postprocessor  can  be  used 
during  a  game  pause  or  after  game  termination. 

1.  Initiation  During  a  Game  Pause 


A  game  pause  occurs  when  the  game  sequence  reaches  a 
CHECK  POINT  command  inserted  by  a  controller  throughout  the 
play  of  the  game.  Within  a  few  seconds  after  the 
recognition  of  the  command,  each  player's  monitor  will 
display  the  word  PENDING  on  the  far  right-hand  side  of  the 
first  text  line  visible  on  the  screen.  Each  player  enters 
READY  to  cause  his  MIP  to  save  important  data  into  a  file. 

The  player  that  logged  on  the  JTLS  system  as  PLAYER01 
is  designated  the  Primary  Controller  for  the  JTLS  exercise. 
The  key  responsibility  of  the  Primary  Controller,  beyond  the 
responsibilities  shared  by  the  other  Controllers,  is  the 
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the  Postprocessor  during  the  game 


decision  to  initiate 
pause . 


When  the  Primary  Controller  invokes  the 
Postprocessor,  the  data  preparation  phase  commences.  During 
this  preparation  phase  all  the  output  produced  since  the 
last  time  the  Postprocessor  was  used  or  since  the  beginning 
of  the  game  (whichever  is  appropriate)  is  transferred  from 
the  game  generated  files  into  the  data  tables  available  in 
the  INGRES  DBMS  [Ref.  8] .  Next,  INGRES  examines  the  data  it 
has  assimilated  and  modifies  the  internal  storage  of  the 
data  to  allow  for  quicker  response  to  a  player's  queries. 

2 .  Initiation  After  Gaming  Session 

To  run  the  Postprocessor  in  "stand-alone'  mode 
(outside  the  context  of  the  gaming  session)  the  player  must 
know  the  name  of  the  Postprocessor  database  that  will  be 
used  for  analysis.  Once  the  player  has  initiated  the  JTLS 
Postprocessor,  he  is  ready  to  retrieve  and  analyze  data  from 
a  particular  Postprocessor  database. 

The  Postprocessor  classifies  queries  in  a 
hierarchical  fashion.  Beginning  at  the  Entry  Menu,  the 
player  decides  which  of  the  four  broad  classes  of  information 
is  of  interest.  These  four  classes  are  combat  systems, 
logistics,  air  assets,  and  targets  [Ref.  4].  After  making 
the  first  choice,  the  player  makes  further  choices, 
narrowing  the  query  to  a  specific  topic.  The  player  directs 
the  search  by  entering  the  number  that  is  displayed  on  the 
menu  next  to  his  choice. 

If  the  query  requires  the  Postprocessor  to  produce  a 
report,  the  player  will  be  prompted  for  a  report  title 
immediately  after  he  selects  that  option.  The  report,  with 
the  security  classification  and  title,  will  be  displayed  on 
the  terminal  screen. 
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A.  INTRODUCTION 


INGRES  is  a  database  management  system  well  suited  for  a 
wide  variety  of  applications.  For  example,  application 
programs  written  in  C  may  access  INGRES  databases  through  a 
SEQUEL  interface  [Ref.  8].  Skilled  database  users  can  meet 
their  information  management  needs  by  utilizing  QUEL,  an 
interactive  non-procedural  query  language.  For  those  using 
INGRES  in  conjunction  with  the  JTLS  game,  a  menu-driven  set 
of  queries  is  provided. 

B.  GENERAL  DESCRIPTION 

INGRES  is  one  of  several  DBMS'  that  does  not  maintain 
any  functional  distinction  between  attributes  and  domains 
[Ref.  8] .  These  two  terms  are  often  used  interchangeably  in 
literature  dealing  with  INGRES.  However,  in  this  thesis 
the  terminology  will  be  restricted  to  the  word  attribute. 
Also  of  particular  interest  is  that  this  lack  of  an  explicit 
domain  does  not  preclude  any  theoretical  implications 
arising  from  the  definition  of  relations  from  the  cartesian 
product  of  a  set  of  value  domains  [Ref.  8]. 

1 .  Database  Constraints 

The  only  global  assertion  which  applies  to  the  entire 
data  base  is  the  distinction  between  the  database  owner  (DBA) 
and  other  users.  There  is  a  system  relation  known  as  the 
USER'S  file  which  contains  the  information  specifying  which 
databases  can  be  opened  and  by  whom. 

The  creation  and  destruction  of  databases  are  tightly 
coupled  to  the  VMS  operating  system.  As  a  result,  INGRES 
enjoys  the  flexibility,  power  and  security  of  the  VMS  file 
management  system.  Also,  INGRES  is  written  in  C,  and 
therefore  requires  a  C  compiler  which  is  available  on  the 
VAX-11  located  in  the  war  laboratory. 
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In  JTLS  the  game  controller  is  given  the 
responsibility  of  the  Database  Administrator.  The  game 
controller  is  privy  to  a  selection  of  commands  unavailable 
to  the  normal  user.  Two  such  commands  relevant  to  the  state 
of  the  database  are: 

CREATDB  -  Establishes  a  new,  initially  empty  database 
with  a  given  name.  The  user  who  issues  the  CREATDB 
command  is  the  owner  of  the  database. 

DESTROYDB  -  Destroy  a  database,  whether  it  is  empty  or 
not . 

A  relation  is  defined  as  a  subset  of  the  cartesian 
product  of  N  sets  of  attribute  values  [Ref.  8]  .  It  is 
generally  assumed  that  the  user' s  perception  of  relation  is 
an  entity  over  which  functions  and/or  predicates  can  be 
evaluated.  It  is  also  possible  to  visualize  a  relation  as  a 
table  in  which  the  tuples  are  always  removed  when  relations 
are  updated. 

There  are  a  number  of  operations  available  in  QUEL 
which  relate  to  the  relation  and  are  extensively  called  by 
the  Postprocessor: 

CREATE  -  Creates  a  new  relation  with  a  given  name. 

The  user  issuing  the  CREATE  command  is  designated  as 
the  relation  owner.  The  owner  of  each  relation  in  the 

fame  is  the  game  itself  as  it  creates  each  needed  file 
or  data  input . 

COPY  -  Appends  the  data  in  a  VMS  file  to  an  existing 
relation  generated  by  the  game. 

DESTROY  -  Deletes  a  named  relation  from  the  database. 

INDEX  -  Creates  secondary  indices  on  existing 
relations. 

MODIFY  -  Defines  the  storage  structure  for  a  relation 
by  specifying  storage  organization  and  keys.  This 
information  is  available  in  Appendix  J. 

SAVE  -  Changes  the  default  relation  expiration  date. 

These  relation  operations  may  be  issued  only  by  the 

owner  of  a  relation. 

3 .  Views 

Views  are  defined  as  a  set  of  dynamically  derived 
relations  [Ref.  9].  A  view  structure  is  essentially  a 
relation  structure  which  has  its  operations  restricted. 


This  function  is  extensively  used  in  JTLS  to  insure  that 
game  players  cannot  access  tables  belonging  to  their 
opponents . 

Views  are  defined  from  relations  in  the  database  by 
the  use  of  the  DEFINE  command.  This  command  is  generated  by 
the  Postprocessor,  which  also  supplies  the  parameters  for 
the  command.  As  with  all  QUEL  commands  the  game  controller 
has  the  option  of  overriding  the  DEFINE  command  as  he  may 
deem  appropriate.  View  definition  can  be  specified  as  a 
subset  of  the  values  in  the  base  relation  by  means  of  a 
qualification  statement  identical  to  those  used  in  retrieval 
commands.  No  other  form  of  view  manipulation  is  possible. 
All  forms  of  retrieval  on  the  view  are  fully  supported. 

Although  views  are  directly  derived  from  relations, 
they  cannot  be  manipulated  as  relations  can  be.  Updates  are 
supported  if  and  only  if  it  can  be  guaranteed  that  the 
result  of  updating  the  view  is  identical  to  that  of  updating 
the  corresponding  real  relation. 

4 .  Tuples 

A  tuple  is  an  instance  of  a  relation.  It  is 
implicitly  defined  when  the  relation  is  created.  Keys  are 
defined  at  the  relation  level  and  only  for  purpose  of 
defining  storage  structures. 

There  is  a  wide  variety  of  operations  in  QUEL  for 

manipulating  tuples.  Since  the  query  language  for  INGRES  is 

based  upon  relational  calculus,  tuples  are  selected  from  a 

relation  which  is  represented  by  a  tuple-variable.  A 

tuple-variable  is  defined  by  use  of  the  RANGE  statement. 

Once  a  tuple-variable  is  defined,  the  definition  remains  in 

effect  until  it  is  redefined  or  the  game  controller  ends  the 

QUEL  session.  Operations  for  manipulating  tuples  are 

completely  controlled  by  the  Postprocessor  and  include: 

APPEND  -  Adds  a  tuple  or  tuples  to  an  existing 
relation . 

DELETE  -  Removes  one  or  more  tuples  from  a  relation. 


REPLACE  -  Modifies  one  or  more  attribute  value  in  one 
or  more  tuples  of  a  relation. 

RETRIEVE  -  Retrieves  a  subset  of  the  tuples  from  a 
relation.  Each  of  these  operations  can  include  an 
optional  qualification  involving  tuple-variables. 

These  qualifications  select  a  subset  of  the  tuples  in 
a  relation  represented  by  a  tuple-variable. 

Tuples  may  be  ordered,  but  only  if  the  storage 
structure  for  the  relation  has  key  ordering.  When  new 
relations  are  formed  from  the  retrieval  of  tuples  or  a 
subset  of  the  attributes  of  the  tuples,  duplicates  are 
always  removed.  Tuples  retrieved  for  display  do  not  have 
duplicates  removed  unless  the  UNIQUE  keyword  is  specified  in 
the  RETRIEVE  statement. 

5 .  Attributes 

The  names  and  characteristics  of  attributes  are 
defined  when  the  relation  which  contains  them  is  defined. 


Attributes  in  conjunction  with  tuple-variables  can  be  used 
in  QUEL  qualifications  statements.  These  attributes  are 
combined  in  qualification  statements  with  boolean  algebra 
and  relational  operators  as  well  as  implicit  existential 
quantification.  The  power  of  the  quantification  statements 
is  extended  by  the  inclusion  of  a  large  library  of 
computational  and  aggregation  functions. 

C.  CV''TEM  ARCHITECTURE 

Operational  Aspects 

INGRES  provides  a  high  level  of  access  control  with 
the  DEFINE  PERMIT  command.  This  command  is  issued  by  the 
Postprocessor  to  restrict  the  access  by  opponent  players  to 
the  relations  and/or  attributes  of  a  relation.  This  command 
is  very  flexible  because  it  also  allows  restriction  of  the 
type  of  operation  which  may  be  performed  like  retrieval, 
update,  etc.,  as  well  as  time-date  access  constraints.  Data 
dependent  access  control  is  supported  since  the  PERMIT 
command  allows  a  qualification  to  be  specified  which 
restricts  access  to  a  subset  of  a  relation  tuple. 
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Though  as  INGRES  is  presently  employed  with  JTLS, 
concurrency  is  not  an  issue,  INGRES  can  support  concurrent 
update  at  the  discretion  of  the  game  controller.  It  uses  a 
preclaim  algorithm  to  avoid  deadlock  [Ref  8]  .  The  locking 
granularity  is  at  the  relation  level  but  has  the  capability 
of  working  at  the  page  level. 


benefits  of  a  Relational  Database 
As  a  ful  Iv  relational  database. 


As  a  fully  relational  database,  INGRES  clearly 
provides  the  following  conveniences  and  facilities  that 
otherwise  would  not  be  available: 


SIMPLICITY  -  INGRES  interfaces  are  based  upon  highly 
usable  extensions  to  the  relational  calculus.  As  a 
result,  a  small  unifgrm  set  of  operations  provides  a 
wide  range  of  selective  power. 

UNIFORMITY  -  As  the  basis  for  INGRES  operations,  the 
relational  calculus  exhibits  closure  [Ref.  8] .  Closure 
is  a  desirable  property  which  simplifies  user 
interaction  with  the  database. 

DATA  INDEPENDENCE  -  As  a  fully  relational  database, 
INGRES  provides  a  high  degree  of  data  independence. 

OPTIMIZATION  -  As  implemented  by  the  Postprocessor, 
information  about  the  storage  structure  themselves 
allow  the  storage  structures  to  be  optimized  [Ref.  8] . 
This  optimization  leads  to  faster  response  times  for 
commonly  used  retrieval  specifications. 

BASIS  FOR  HIGH  LEVEL  INTERFACES  -  The  data 
independence,  simplicity  and  uniformity  of  INGRES  data 
representation  and  operation  make  high  level  interfaces 
possible  and  practical. 

SECURITY  -  Security  seems  to  be  a  distinct  advantage 
to  relational  databases  since  the  access  control  rules 
for  DEFINE  and  DEFINE  PERMIT  use  the  same  techniques  as 
other  operations  like  retrieval  and  update. 
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V.  ORACLE  DATABASE  MANAGEMENT  SYSTEM 


A.  INTRODUCTION: 

Relational  Software  Incorporated  (RSI)  began  development 
of  ORACLE  database  in  1977  and  demonstrated  a  prototype 
relational  system  in  1978.  The  first  copy  of  the  ORACLE 
Database  Management  System  (DBMS)  was  delivered  for  public 
use  in  June  1979.  RSI  claims  that  ORACLE  is  a  DBMS 
especially  designed  for  those  personnel  with  minimal 
computer  experience . 

RSI  also  promotes  ORACLE  as  especially  useful  in  an 
environment  in  which  the  DBMS  must  interact  with  several 
different  computer  hardware  systems  and  different  operating 
systems.  Several  versions  of  the  software  have  been 
developed  specifically  to  exploit  the  peculiarities  and 
idiosyncrasies  of  specific  machines  and  operating  systems. 
A  version  of  ORACLE  exclusively  designed  for  use  on  the  Sun 
Workstation,  and  developed  to  interact  and  exploit  system 
services  on  the  UNIX  is  now  available  for  installation  in  the 
War  Laboratory.  These  characteristics  enhance  the  speed  and 
efficiency  that  queries  can  be  processed  by  ORACLE. 

B.  IMPLEMENTAION 

These  several  features  have  proven  to  be  significant 
factors  in  the  currently  favorable  interest  expressed  by  the 
proponents  of  JTLS. 

1 .  General  Description 

The  hardware  requirements  of  the  ORACLE  DBMS  are  very 
similar  to  those  of  INGRES.  A  memory  allocation  of  at  least 
4  megabyte  is  required.  The  disk  space  of  14,000  IK  blocks 
for  ORACLE  DBMS  distribution  and  task  images  are  also  a 
necessity.  The  database  uses  at  least  4500  IK  blocks  for 
the  user  database  files  and  before  image  files.  The  Sun 
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UNIX  operating  system  release  3.2  or  later  is  needed  to  run 
ORACLE  on  the  Sun  Workstation. 

The  ORACLE  DBMS  architecture  takes  advantage  of 
several  Sun  UNIX  features  that  allow  an  ORACLE  system  to 
share  both  executable  code  and  data  among  several  programs . 
These  features  are  outlined  below: 

1)  System  Global  Area  -  The  SGA  is  a  shared  memory 

region  that  permits  multiple  applications  or  users 
to  access  the  same  data.  All  ORACLE  programs  must 
have  access  to  the  common  data  structures  that  the 


SGA 

contains : 

a) 

locks. 

b) 

queues. 

c) 

transaction  recovery 

information 

d) 

process  control  information, 

e) 

system  configuration 

information 

f) 

before  image  buffers. 

and 

g) 

database  buffers. 

Each  active  ORACLE  system  has  one  SGA  which 
contains  the  locations  for  its  database  files  and 
before  image  files. 

2)  Shadow  process  -  In  the  two  task  architecture  of 
ORACLE  implementation,  each  application  task 
starts  a  corresponding  shadow  task.  The  shadow 
task  constitutes  the  ORACLE  kernel,  and  is  the 
only  foreground  process  that  has  access  to  the  SGA. 

3)  Interprocess  Communication  -  Interprocess 
communication  is  the  ability  to  transfer  either 
control  or  data  information  from  one  process  to 
another.  Under  Sun  UNIX,  a  variety  of  two-  task 
drivers  may  be  used  for  this  purpose. 

2 .  Data  Structure 

The  ORACLE  database  system  is  composed  of  a  database, 
and  its  relations,  views,  tuples,  records  and  domains. 
These  database  components  are  interrelated  in  the  following 
manner.  A  relational  database  consists  of  relations  of 
possibly  many  different  types.  A  relation  consists  of 
tuples  of  the  identical  type.  A  view  is  derived  from  one  or 
more  relations  by  means  of  a  projection  and  the  subsequent 
use  of  the  qualification  operations.  A  tuple  consists  of 
item  values  of  possibly  different  types.  A  domain  is 
defined  in  terms  of  a  user  defined  data  type. 


An  ORACLE  database  consists  of  a  set  of  relation 
definitions  which  are  stored  in  system-maintained  relations. 
It  also  consists  of  a  set  of  stored  tuples  for  each  relation 
and  a  set  of  views.  A  view  is  simply  a  set  of  virtual 
relations  defined  on  base  relations  [Ref. 9].  A  database  is 
named  by  assigning  the  user  created  name  to  the  file  when  the 
database  is  initially  created. 

A  relation  is  defined  as  a  two  dimensional  table  of 
data  items.  This  allows  the  visualization  of  a  relation  as 
a  table  of  rows  and  columns.  These  relations  within  a 
database  are  assigned  unique  names  at  the  time  of 
definition.  In  ORACLE  duplicate  tuples  are  permitted, 
although  the  system  will  enforce  a  uniqueness  requirement 
for  a  primary  key  if  it  is  specified  in  the  definition. 

ORACLE  supports  a  uniqueness  requirement  for  any 
attribute  the  user  wishes  to  use  as  a  primary  key.  Primary 
keys  must  be  indexed.  In  addition,  the  system  will  reject 
the  NULL  values  in  inserted  or  updated  tuples.  The  first 
attribute  defined  for  a  relation  must  be  assigned  a  value 
when  a  tuple  is  inserted. 

3 .  Set  Operations 

Qualification  in  ORACLE  is  calculus  oriented 
[Ref. 10].  Qualification  results  may  be  thought  of  as  a 

relation  populated  with  qualified  rows.  Qualification  can 
be  used  with  retrievals,  updates  and  deletion. 

Set  operations  are  not  directly  supported  by  ORACLE. 
Instead,  they  are  accomplished  using  combinations  of  other 
SQL  operators.  JOIN,  in  ORACLE,  is  handled  by  means  a  of 
restriction  in  the  selection  criteria  subject  to  the 
following  constraints: 

1)  reflexive  JOINS  require  using  a  different  table 
name  for  each  table  reference  to  the  base  relation, 
and 

2)  up  to  255  relations  can  be  joined,  and 

3)  items  used  for  specifying  JOINS  need  not  be 
indexed. 


The  queries  for  the  INGRES  DBMS  were  written  in  QUEL. 
Since  the  queries  used  by  the  players  were  entirely  menu 
driven,  a  great  deal  of  interaction  was  required  between  the 
INGRES-based  application  programs  and  the  VMS  operating 
system.  This  same  situation  is  repeated  with  the  use  of  the 
ORACLE  DBMS.  The  queries  will  again  be  totally  menu  driven, 
requiring  the  ORACLE  application  programs  to  interface  with 
the  UNIX  operating  system.  In  ORACLE  this  will  be  made 
relatively  simple  by  using  the  SQL*C  language  provided. 

SQL*C  is  a  self-contained  language  used  for  data 
definition,  selection,  query,  update  and  interfacing  with 
other  compatible  environments.  It  is  also  used  to  define 
relations  and  attributes,  to  insert,  modify  or  delete 
tuples,  and  to  retrieve  relations  or  projections  on 
relations.  Finally,  it  can  be  used  to  take  advantages  of 
system  routines  already  available  in  UNIX  or  used  to  create 
needed  subroutines  to  achieve  a  desired  effect.  The 
SQL*C  commands  are  relatively  straightforward  using  a  great 
number  of  mnemonics  and  English  keywords.  For  example, 
selection  is  based  on  relational  calculus  with  the  criteria 
specified  in  a  WHERE-clause .  The  language  is  user-driven  and 
is  normally  intended  for  ad  hoc  query  and  update.  To 
accomplish  this  SQL*C  can  be  used  on  a  stand-alone  basis, 
but  more  usefully  it  can  be  embedded  in  user-written 
programs  to  facilitate  the  construction  of  menus  and  program 
interfaces . 

5 .  Security  Features 

As  with  the  INGRES  DBMS,  views  are  again  extensively 
used  in  ORACLE  to  accommodate  the  JTLS  game  play.  Views  are 
used  to  limit  player  access  to  specific  columns  of  a  table 
or  to  selected  tuples.  Views  also  provide  a  means  for 
restricting  types  of  access  such  as  read  or  write  and  by 
whom.  In  ORACLE,  views  are  defined  as  dynamic  virtual  tables 
comprised  of  a  selected  portion  of  the  database.  Since  the 
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views  are  derived  by  selecting  qualified  tuples  from  the 
base  relations,  the  keys  are  inherited  from  the  base 
relations . 

In  addition  to  the  VIEW  feature,  the  Sun  UNIX 
provides  additional  security  assets.  These  features  include 
file  ownership,  group  accounts  and  the  ability  to  have  a 
program  change  its  user-id  upon  execution. 

Security  is  also  enhanced  by  the  two-task 
architecture  of  the  ORACLE  DBMS  implementation.  A  division 
of  work  and  address  space  exists  between  the  user  program 
and  the  ORACLE  program.  This  allows  an  enhanced  security 
scheme  since  all  database  access  is  achieved  through  the 
shadow  process  and  special  authorizations  on  the  ORACLE 
program. 
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VI.  THE  OPEN  SYSTEM  INTERNET  MODEL 


A.  INTRODUCTION 

Within  Department  of  Defense  (DOD)  the  internet  protocol 
most  commonly  used  is  IP  [Ref.  3].  For  this  reason  the  U.S. 
Army  has  expressed  much  interest  in  utilizing  this  network 
component  in  its  distributed  war  games .  The  current 
configuration  of  JTLS  will  need  to  be  modified  to  include 
the  capacity  to  incorporate  internet  communications.  This 
proposal  is  currently  under  consideration  by  the  responsible 
proponents  of  JTLS. 

For  the  sake  of  standardization,  the  generic  network 
system  is  designed  as  a  series  of  layers  with  each  layer 
performing  a  specific  function  called  a  protocol.  Through 
this  hierarchy  of  protocol  layers,  it  is  made  much  easier 
for  one  computer  system  to  establish  a  communication  link 
with  another  computer  system,  and  pass  the  desired  data 
correctly  across  the  network.  Also  this  system  of  hierarchy 
precludes  any  of  the  higher  levels  being  concerned  about  any 
of  the  low  level  functions  required.  To  provide 

communication  services,  each  layer  must  exchange  the 
required  signals  with  its  peer  layer  across  the  network. 

Stratifying  the  network  system  allows  each  layer  to  view 
its  set  of  lower  layers  as  providing  the  services  needed  to 
complete  its  role  in  the  networking  hierarchy.  The  means  by 
which  the  lower  layer  accomplishes  this  task  is  of  no 
concern  to  the  upper  layer.  Of  particular  interest  in  this 
thesis  are  the  roles  the  IP  and  TCP  layers  play  in  the 
network  hierarchy. 

B.  INTERNET  PROTOCOL 

1 .  DESCRIPTION 

The  Internet  Protocol  (IP)  is  designed  to  provide  the 
necessary  functions  to  deliver  a  package  of  bits  (datagram) 
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1  from  one  host  to  another  [Ref.  11] .  The  IP  has  a  number  of 

‘  features  which  enable  the  protocol  to  send  datagrams  across 

connected  networks.  The  first  of  these  features  allow  the 
IP  datagrams  to  be  fragmented  into  smaller  packets.  This  is 

i 

I  extremely  useful  when  the  intervening  networks  do  not 

permit  packets  as  large  as  the  created  intact  datagram  to 
cross.  These  fragments  can  then  be  reassembled  at  their 
destination  using  information  contained  in  the  IP  header 
[Ref.  11].  Since  it  is  expected  that  all  data  generated  by 
the  game  will  be  sent  over  a  single  network,  this  feature 
will  not  be  elaborated. 

For  most  networking  tasks,  the  minimum  underlying  raw 
data  transfer  services  provided  by  the  Data  Link  Layer  is 
too  limited.  Thus,  the  second  major  feature  of  the  IP  is  to 
provide  the  needed  power  to  transmit  data  through  the 
internet  at  the  Network  layer.  Basically,  the  job  of  the  IP 
is  to  interconnect  one  or  more  packet  handling  networks 
into  an  internet.  The  IP  provides  its  services  to  various 
upper  layers  by  assisting  the  delivery  of  these  data  packets 
through  the  internet.  The  IP  is  limited  to  the  basic 
functions  required  for  delivering  a  datagram  through  an 
internet.  Each  IP  datagram  crossing  an  internet  is  an 
independent  entity,  unrelated  to  any  other  datagram  [Ref. 
11].  The  host's  IP  layer  provides  services  to  the  Transport 
layer  and  relies  on  services  from  the  Data  Link  layer.  The 
IP  layer  takes  data  sent  by  a  Transport  layer  and  uses  the 
services  of  the  Data  Link  layer  to  forward  the  data  to  the 
IP  layer  of  the  destination  host . 

The  IP  does  not  promise  a  reliable  service.  Hosts 
receiving  IP  datagrams  will  discard  the  datagrams  when 
insufficient  resources  are  available  for  processing,  and 
will  not  detect  datagrams  lost  or  discarded  by  the  Data  Link 
layer. 

The  IP  insulates  the  upper  layers  from  any  network 
specific  characteristics.  To  accomplish  this  an  additional 
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service  provided  by  the  IP  includes  selectable  levels  of 
transmission  behavior  involving  such  characteristics  as 
precedence,  reliability,  delay  and  throughput.  The  IP  also 
allows  data  labeling  which  is  needed  in  secure  environments 
to  associate  security  information  with  data. 

2 .  Implementation 

Transmission  begins  when  a  protocol  of  an  upper  layer 
passes  data  to  the  IP  for  delivery.  The  IP  packages  the 
data  as  an  internet  datagram  and  passes  it  to  the  Data  Link 
protocol  layer  for  transmission  across  the  local  net.  The 
IP  sends  the  datagram  through  the  network  directly  to  the 
host . 

The  IP  does  not  only  provide  services  to  the  upper 
level  protocols.  It  requires  support  from  the  lower  levels, 
including  a  transparent  data  transfer  between  hosts  with  a 
single  subnetwork  as  well  as  error  reporting.  Datagrams  may 
not  necessarily  arrive  in  the  same  order  they  were  supplied 
to  the  subnetwork  layer,  nor  is  data  guaranteed  to  arrive 
error  free.  The  lower  level  provides  reports  to  the  IP 
indicating  errors  from  the  subnetwork  and  lower  layers,  as 
feasible.  The  specific  error  requirements  of  the  subnetwork 
layer  are  dependent  on  the  individual  subnetwork.  Ethernet, 
the  DECNET  software  in  use  in  the  war  laboratory,  does  not 
generally  report  errors  except,  for  example,  when  a 
particular  packet  needs  to  be  discarded  because  of  16 
consecutive  collisions  [Ref.  12]  .  Since  the  IP  datagram 
delivery  is  not  considered  infallible,  how  an  IP  module  will 
react  to  information  from  a  lower  layer  about  the 
disposition  of  a  particular  packet  is  largely  unspecified. 


C.  TRANSMISSION  CONTROL  PROTOCOL 
1 .  Description 

Generally  TCP  provides  services  at  the  Transport 
Layer  and  IP  provides  services  at  the  Network  Layer.  The 
Transport  layer  is  designed  to  provide  a  machine  with 
end-to-end  subnet  independent  connections  and  transaction 
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services.  The  lower  layers  of  the  International 
Standardization  Organization  (ISO)  model  are  concerned  with 
the  transmission,  framing  and  routing  of  packets  between 
machines.  The  Transport  layer,  however,  has  the  task  of 
providing  reliable  and  efficient  end-to-end  transmission 
services  between  processes  rather  than  simply  between 
machines.  All  four  levels  -  physical,  data  link,  network  and 
transport  -  work  together  to  provide  a  complete  transport 
service.  Providing  the  robust  and  transparent  communications 
upon  which  upper  levels  of  protocols  may  then  be  built. 

TCP  is  designed  to  operate  over  a  wide  variety  of 
networks  and  to  provide  virtual  circuit  service  with 
orderly,  reliable  transmission  of  the  user  data.  The 
virtual  circuit  concept  is  implemented  by  associating  a 
series  of  packets  with  one  another.  The  goal  of  this 
association  is  to  provide  a  service  by  which  applications 
can  talk  with  one  another  just  as  though  they  had  a 
physical  point-to-point  link  [Ref.  11]. 

2 .  Implement at ion 

TCP  supports  a  wide  range  of  upper  level  protocols 
which  need  to  send  data  to  their  peers  on  the  other  host. 
TCP  does  not  attempt  to  impose  any  structure  on  the  data 
sent  by  a  given  upper  level  protocol.  It  simply  treats  the 
upper  level  protocol  data  as  though  it  were  a  continuous 
stream,  thereby  leaving  all  notions  of  message  structure  in 
the  hands  of  the  upper  level  protocols  themselves.  TCP  does 
however,  attempt  to  segment  the  stream  into  discreet  units 
so  it  can  be  sent  and  received  in  individual  packets.  Each 
of  these  packets  is  called  a  segment. 

To  maintain  a  reliable  host-to-host  connection  for 
the  purpose  of  transferring  data,  tl  :  TCP  functions  include 
establishing  internet  connections,  transferring  data  and 
ensuring  adequate  flow  control.  A  major  function  of  TCP  is 
to  provide  data  connections  between  pairs  of  upper  level 
protocols.  Before  any  data  transfer  can  occur,  a  connection 
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has  to  be  made  between  the  two  hosts.  TCP  does  this  through 
the  use  of  a  three-way  handshake.  Port  numbers  are  assigned 
to  each  end  of  the  connections  to  identify  the  logical 
channels  to  which  the  data  should  be  sent  at  each  host.  TCP 
is  also  responsible  for  breaking  the  connection  once  the 
application  layer  is  finished.  This  activity  is  referred  to 
as  connection  management.  Connection  management  can  be  broken 
down  into  three  phases: 

1)  connection  establishment, 

2)  connection  maintenance,  and 

3)  connection  termination. 

Connections  are  endowed  with  certain  properties  that 
apply  for  the  lifetime  of  the  connection,  including  security 
and  precedence  levels.  These  properties  are  specified  by 
the  upper  level  protocols  at  connection  openings.  TCP 
provides  a  means  for  a  upper  level  protocol  to  actively 
initiate  a  connection  to  another  upper  level  protocol 
uniquely  named  with  a  socket.  A  socket  is  actually  the 
concatenation  of  an  IP  address  with  the  application's  port 
number  [Ref.  11].  A  connection  is  defined  by  the 
combination  of  the  two  participants'  socket  numbers. 

Once  a  connection  has  been  established,  TCP  will 
maintain  it  as  long  as  both  parties  are  interested  in 
keeping  it  active.  Connections  which  are  established  but 
which  are  not  actively  sending  user  data  do  not  generate  any 
packets.  This  is  not  a  problem,  but  it  is  interesting  that 
TCP  does  not  specify  a  mechanism  for  detecting  the  loss  of  a 
connection  partner  when  no  data  are  being  exchanged.  But 
since  for  some  applications  such  information  is  of  use,  some 
TCP  implementations  use  a  trick  to  accomplish  the  detection. 
They  send  a  datagram  with  no  data  and  an  incorrect  sequence 
number.  TCP  specifies  that  the  recipient  must  respond  with 
a  datagram  indicating  the  correct  sequence  number.  If  no 
response  is  received,  the  probing  TCP  may  be  able  to  decide 
that  its  peer  has  disappeared. 
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Established  connections  can  be  terminated  in  either 
of  two  ways: 

1)  Graceful  close  -  Both  upper  level  protocols  close 
their  side  of  a  duplex  connection,  either 
simultaneously  or  sequentially,  when  data  transfer 
is  complete. 

2)  Abort  -  When  one  upper  level  protocol  unilaterally 
forces  closure  of  the  connection,  TCP  does  not 
coordinate  connection  termination. 

Flow  control  mechanism  permits  a  receiving  TCP  to 
govern  the  amount  of  data  dispatched  by  a  sending  TCP.  The 
mechanism  is  based  on  a  window  which  defines  a  contiguous 
range  of  acceptable  sequence  numbered  data.  As  data  are 
accepted,  TCP  slides  the  window  upward  in  the  sequence 
number  space.  The  current  window  is  specified  in  every 
segment  and  enables  the  peer  TCPs  to  maintain  up-to-date 
information . 


VII.  PROGRAMS 


A.  INTRODUCTION. 

The  files,  code,  code  description,  and  variable 
descriptions  for  programs  are  in  Appendices  A  through  L.  The 
flowcharts  are  in  Appendix  L.  The  Appendices  are  provided  to 
compliment  the  following  discussion,  and  to  support  the 
actual  implementation  of  the  feasibility  test. 

B.  PUSH  PROGRAM 

1 .  Files 

Conceptually,  the  Push  program  has  been  developed  to 
simulate  JTLS  pushing  game  data  onto  the  internet  as  if  the 
game  were  in  progress.  In  practice,  the  program  uses  data 
files  from  a  completed  game,  and  transmits  individual 
records  from  these  files  across  the  network  to  the  Sun 
Workstation.  The  program  sends  these  records  in 

chronological  order  simulating  sending  these  records  as  if 
they  were  being  generated  by  the  game.  To  accomplish  this 
the  time  attribute  from  each  record  is  determined  and 
compared  with  the  Push  program  generated  clock.  Additionally 
the  order,  domain  and  ranges  of  each  record  attribute  must  be 
determined  and  entered  correctly  on  the  Sun  Workstation. 
This  entailed  a  complete  analysis  of  the  data  files  as  the 
first  step  in  the  development  of  the  Push  program.  The 
Postprocessor  User  Guide  [Ref.  4]  contains  an  administrative 
listing  of  tables  and  attributes  assembled  in  alphabetical 
order.  Also  the  size  of  each  numeric  column  is  described  in 
byte  size,  rather  than  the  number  of  required  characters  as 
required  by  ORACLE.  A  comparison  of  the  game  files  with  the 
Postprocessor  User  Guide  [Ref.  4]  and  the  Data  Requirements 
Manual  [Ref.  13]  furnished  an  assessment  of  attribute  order 
and  ranges . 


Sixty  of  the  sixty  nine  Postprocessor  files  are 
generated  by  the  CEP  and  can  be  utilized  by  the  Push 
program.  The  DATA_BASE,  DICTIONARY,  and  DIRECTORY  files 
contain  administrative  data  and  reside  permanently  on  ohe 
Sun  Workstation.  The  files  COMBATSYS,  REASONS,  SUPPLIES, 
TARGETS,  and  UNITS  are  produced  by  the  Scenario  Preparation 
Program,  and  are  used  to  match  data  produced  by  the  CEP  for 
report  format  purposes.  The  parameters  of  these  data  tuples 
can  be  manipulated  by  the  game  controller.  These  files 
should  be  transmitted  to  the  Sun  Workstation  prior  to  the 
game.  A  subset  of  the  CEP  produced  files  associated  with 
aircraft  was  selected  for  the  demonstration  of  the  Push 
program.  The  first  step  of  the  program  was  to  create  a 
corresponding  time  file  for  each  data  file  to  determine  when 
a  game  record  should  be  transmitted  across  the  network.  A 
time  file  was  linked  to  the  appropriate  JTLS  data  file  by  a 
logical  unit  number.  Each  data  file  was  assigned  a  unique 
logical  unit.  The  numbers  started  at  10  to  prevent  utilizing 
a  unit  number  reserved  by  the  operating  system.  The 
corresponding  time  file  was  initially  given  the  same  logical 
unit  assignment.  However,  in  doing  this  the  desired  results 
were  not  obtained.  For  reasons  unknown  this  method  did  not 
send  data  in  the  prescribed  order.  This  was  corrected  by 
reassigning  the  time  file  the  next  sequential  number  of  its 
linked  relation  data  file.  The  maximum  number  that  can  be 
assigned  to  a  logical  device  is  ninety  nine.  As  a  result  a 
maximum  of  forty  five  data  files,  and  forty  five  time  files 
can  be  used  in  this  program.  Each  time  file  was  created  by 
using  a  definite  iterative  DO-loop.  The  loop  control 
variable,  UNT,  was  initiated  to  the  value  of  the  first 
logical  unit  number,  increased  by  two,  and  terminated  with 
the  value  of  the  last  logical  unit  number.  Each  loop 
iteration  invokes  subroutine  GETIME  to  create  the  time  file. 


The  data  and  associated  time 
subsequent  processing. 


files  are  rewound  for 
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2.  GETIME  Routine 


Subroutine  GETIME  reads  the  first  thirteen  characters 


of  a  data  record  into  a  character  string  to  determine  the 
elements  of  the  time  attribute.  Data  analysis  revealed  that 
the  attribute  TIME  is  the  second  attribute  in  all  files, 
preceded  by  the  attribute  INTRVL.  Although  the  range  for 
INTRVL  is  32767,  interviews  with  JTLS  contractors  revealed 
the  possibility  that  the  length  of  INTRVL  exceeding  one 
character  is  remote.  Further  study  of  the  data  determined 
the  minimum  number  of  characters  in  attribute  TIME  is  two, 
and  the  maximum  number  is  ten.  Therefore,  only  the  first 
thirteen  characters  of  each  record  were  required  to  be  read; 
one  character  for  the  interval,  ten  for  the  time,  and  two 


for  delimiters 


The  subroutine  then  examines  elements  of  the  array 
beginning  with  the  third  element  (skips  INTRVL  and  the  first 
delimiter)  until  the  second  delimiter  is  located.  The 
length  of  the  attribute  is  then  determined.  Once  the  length 
is  computed  the  required  number  of  character  concatenations 
is  determined  and  executed. 

The  concatenation  process  appears  to  be  rather 
awkward  as  written.  It  was  originally  implemented  as  a 
definite  iterative  DO-loop  structure.  For  reasons  unknown, 
the  loop  did  not  concatenate  the  array  elements,  and  a 
series  of  IF-THEN  decisions  were  implemented  in  lieu  of  the 
loop.  Finally,  the  subroutine  reclassifies  TIME  from  a 
character  variable  to  a  real  variable  to  allow  comparison 
with  the  Push  program  generated  timer. 

Although  each  time  and  data  file  is  in  sequential 
order,  records  read  from  each  file  must  be  compared  against 
each  other  to  ensure  data  is  sent  across  the  network 
chronologically.  An  array  type  of  real  numbers,  TMARY,  is 
implemented  to  contain  a  time  record  from  each  of  the  time 
files.  An  array  type  of  integers,  UTARY,  is  implemented  to 
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contain  the  corresponding  logical  unit  number  of  the  time 
record. 

The  TMARY  array  is  sorted  in  descending  order,  while 
the  UTARY  array  mirrors  the  required  sorting  interchanges. 
This  enables  the  program  to  order  the  logical  unit  of  the 
time  file  which  in  turn  points  to  the  correct  data  record  in 
the  appropriate  data  file  to  be  read  and  transmitted.  The 
routine  IARAYS  places  the  first  record  of  each  time  file  and 
its  corresponding  logical  unit  number  into  TMARY  and  UTARY 
respectively.  The  variable  INDEX  is  used  to  indicate  array 
position.  When  the  subroutine  is  finished,  INDEX  is  assigned 
the  value  1.  Contriving  this  eliminates  the  need  for  two 
read  routines.  The  RDTME  routine  is  used  both  to  initiate 
and  update  TMARY. 

After  the  arrays  are  initialized,  the  records  are 
sorted  and  transmitted  until  all  of  the  files  are  empty. 
When  a  file  is  empty  the  subroutine  COMPACT  is  invoked  to 
decrement  the  counter  of  open  files,  increment  the  counter 
of  closed  files,  and  shift  elements  of  the  arrays  to  the 
left  1  unit.  The  counter  for  empty  files  is  used  to 
terminate  the  program  when  the  counter  is  equal  to  the 
number  of  initially  opened  files.  The  counter  for  the 
remaining  open  files  is  used  to  provide  the  sort  routine  with 
the  element  comparison  range  and  the  elements  in  the  left 
most  position  are  no  longer  required  because  that  file  is 
empty.  This  increases  the  efficiency  of  the  sort  routine  by 
eliminating  unnecessary  comparison. 

3 .  SORT  Routine 

The  sort  routine  selected  for  this  program  is  a 
slight  variation  of  the  Bubblesort  and  uses  the  time  records 
from  the  time  files  as  objects  of  its  sort.  As  previously 
stated  all  records  within  each  individual  file  are  already 
ordered,  drastically  reducing  the  number  of  required 
comparisons  and  interchanges.  We  found  this  sort  routine  to 
be  the  most  efficient  one  to  our  knowledge  for  sorting  an 


array  that  is  predominantly  arranged  in  order.  This 
variation  of  Bubblesort  was  contrasted  with  the  original 
Bubblesort,  Shakesort,  Quicksort,  and  Heapsort  and  found  to 
have  the  least  number  of  comparisons  and  interchanges  for  an 
ordered  array. 

The  outer  loop  in  the  sort  routine  sets  the  terminal 
condition,  MORE,  to  false  and  adjusts  the  comparison  range  if 
required.  The  inner  loop  is  used  to  make  the  comparisons  and 
interchanges.  If  an  interchange  is  not  required  on  any 
iteration  of  the  inner  loop,  the  array  is  assumed  sorted  and 
the  routine  terminates.  Upon  completion  of  the  sort  routine 
the  data  file  containing  the  next  record  for  transmission  is 
determined. 

4 .  CHCLR  Routine 

After  the  correct  data  file  has  been  identified  it  is 
then  necessary  to  resolve  when  the  record  is  to  be  read  and 
transmitted.  This  is  accomplished  in  subroutine  CHCLK .  When 
the  value  of  the  program  clock  is  equal  to  the  record  clock 
the  appropriate  data  record  is  read  and  sent  through  the 
network.  If  the  times  are  not  equal,  the  program  clock  is 
incremented,  by  0.00001  until  the  times  are  equivalent.  The 
program  clock  is  compared  with  the  time  record  after  each 
increment . 

The  purpose  of  the  program  clock  is  simply  to  cause 
a  delay  in  transmission  utilizing  a  counter  to  represent  a 
break  in  the  data  stream.  This  delay  is  simply  in  terms  of 
the  relative  amount  of  time  the  game  player  would  normally 
wait  until  that  data  set  would  appropriately  be  available 
for  query  purposes . 

Prior  to  sending  the  data  across  the  network,  the 
data  record  is  tagged  with  an  identifier  and  delimiter  in 
subroutine  SNDREC.  The  tag  permits  the  Pack  program,  on  the 
Sun,  to  determine  for  which  table  the  record  destined.  The 
actual  data  transmission  is  performed  by  utilizing  the 
remote  file  access  routine  available  in  the  FORTRAN  Library 


on  the  VAX-11.  Following  data  transmission  the  RDTME  reads 
the  next  time  record  from  the  corresponding  time  file  of  the 
record  just  transmitted  into  the  TMARY .  The  process 
continues  until  all  the  records  have  been  sent  across  the 
network . 


C.  PULL  PROGRAM 

1 .  Incoming  Game  Files 

The  Pull  program  runs  in  the  background  mode  timesharing 
with  the  PACK  program,  also  running  in  the  background  mode. 
The  Pull  program  places  data  which  has  been  sent  across  the 
network  by  the  Push  program  into  one  of  two  data  files 
located  on  the  Sun  Workstation.  These  two  data  files 
designated  GAME1.DAT  and  GAME2.DAT  are  selected  to  be 
written  or  read  depending  on  the  status  of  the  global  read 
lock  (RLCK)  and  write  lock  (WLCK)  variables. 

2 .  Read  Lock,  Write  Lock 

Prior  to  accepting  data  from  the  VAX-11,  the  Pull 
program  checks  the  status  of  the  global  variables  RLCK 8  or 
RLCK9  to  see  if  GAME1.DAT  or  GAME2.DAT  respectively  is  being 
read  by  the  Pack  program.  If  the  read  lock  status  is  equal 
to  0  the  file  is  available  to  be  written  into  by  the  Pull 
program.  Access  by  the  Pack  program  to  read  a  file  is 
disabled  by  setting  the  write  lock  variables,  WLCK8  or 
WLCK9,  equal  to  1.  The  Pull  program  then  opens  the  file, 
accepts  data  from  the  VAX-11,  writes  data  to  the  file, 
closes  the  file,  and  resets  the  write  lock  variable  back  to 
0.  This  sequence  is  executed  for  each  data  set  written  into 
the  file. 

The  Pull  program  alternates  writing  between  GAME1.DAT 
and  GAME2.DAT.  The  actual  file  that  is  selected  to  be 
written  into  depends  on  the  RLCK  status  of  the  chosen  file. 
This  alternation  of  the  files  continues  until  GAME1.DAT  is 
closed  by  the  Push  program.  This  closure  signals  the  Pull 
program  that  there  is  no  more  data  to  be  received  at  its 
end.  The  Pull  program  sets  NOMO  to  TRUE,  informing  the  Pack 
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program  that  no  more  data  are  to  be  read  while  in  the 
REPEAT-UNTIL  loop. 


D.  THE  PACK  PROGRAM 


1 .  Implementation 


The  Pack  program  initially  attempts  to  read  file 
GAME1.DAT  and  busy  wait  until  WLCK8  is  set  to  0.  Because 
WLCK8  is  initialized  to  1  in  the  Pull  program,  the  Pack 
program  will  not  access  GAME 1 . DAT  until  at  least  one  set  of 
data  is  available  to  be  read.  Once  access  to  GAME1.DAT  is 
obtained  by  the  Pack  program,  the  RLCK8  variable  is  set  to 
1.  This  action  denies  access  to  GAME1.DAT  by  the  Pull 
program.  When  all  records  have  been  processed  by  the  Pack 
program,  RLCK8  is  set  to  0  and  access  by  the  Pull  program  is 
again  permitted.  The  Pack  program  will  then  busy  wait  to 
read  GAME2.DAT  until  access  is  granted. 

While  reading  GAME2.DAT  during  the  last  iteration, 
the  Pull  program  could  be  writing  for  the  last  time  into 


GAME1.DAT  and  set  the  variable  NOMO  to  true.  To  read  and 


process  this  data  the  Pack  program  will  exit  the 
REPEAT-UNTIL  loop,  open  GAME1.DAT,  read  the  stored  data,  and 
place  the  data  into  the  proper  table.  When  the  EOF  is  read, 
the  Pack  program  terminates.  It  is  not  necessary  to  perform 
this  read  procedure  on  GAME2.DAT  because  of  the  program 


structure . 


Database  Tables 


When  a  record  has  been  read  from  either  GAME1.DAT  or 


GAME2.DAT,  it  must  be  parsed,  reassembled  into  its  correct 
form,  and  finally  placed  into  the  appropriate  JTLS  table. 
The  first  step  in  this  process  is  to  extract  the  table 

identifier  and  attributes  from  the  data  record.  Except  the 

first  and  last  items,  the  individual  data  items  are 

delineated  by  the  delimiter  on  either  side  of  the 

component.  A  space  denotes  the  end  of  the  record.  The  search 
for  attributes  continues  until  a  space  has  been  located. 
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which  sets  the  loop  terminal  condition,  MORE,  false  and  ends 
the  process. 

Each  element  of  the  character  array  RCD  is  examined 
by  the  program.  If  the  character  read  is  not  a  space  or 
delimiter  the  variable  LEN,  used  to  identify  the  field 
length,  is  incremented.  The  next  element  of  the  array  is 
then  examined.  If  a  delimiter  is  read,  the  subroutine 
CONCAN  is  called  to  concatenate  the  appropriate  elements 
into  a  single  character  string  variable  ATTR.  The  variable 
POS  is  the  beginning  element  location,  and  LEN  determines  the 
number  of  required  concatenations.  Upon  return  from 
subroutine  CONCAN,  subroutine  CONVRT  is  called  to  determine 
which  attribute  the  string  represents. 

When  the  variable  ANUM  is  set  to  1,  the  variable  ATTR 
represents  the  table  identifier.  The  table  identifier  is 
subsequently  used  with  specific  values  of  ANUM  to  determine 
placement  of  ATTR  into  the  database  tables.  The  variable 
ATTR  is  then  transformed  to  the  appropriate  data  type  for 
insertion  into  the  database  table.  The  programs  returns  to 
subroutine  FNDATT  which  prepares  the  variables  ANUM,  LEN, 
I NX  and  POS  for  the  next  string. 

Subroutine  ENTTUP  writes  data  into  the  appropriate 
table.  The  corresponding  read  lock  variable  is  tested  to 
gain  control  of  the  desired  database  table.  If  RLCK  is 
equal  0,  WLCK  is  assigned  1  to  prohibit  the  query  program 
from  gaining  access.  The  data  is  then  written  to  the  table, 
and  WLCK  is  reassigned  0  to  allow  queries.  If  RLCK  is  equal 
to  1  the  program  will  busy  wait  attempting  to  gain  access 
until  the  query  program  sets  RLCK  to  0. 


VIII.  RELATIONAL  DATABASE  DESIGN 


A  relational  database  design  has  been  included  to 
facilitate  the  implementation  of  the  ORACLE  database  on  the 
Sun  Workstation.  A  logical  database  design  specifies  the 
logical  format  of  the  database,  the  records  to  be 
maintained,  their  contents,  and  the  relationships  among  those 
records  [Ref  14]  .  The  logical  design  is  then  transformed 
into  a  relational  database  design,  which  is  compatible  with 
ORACLE  and  contains  detailed  specifications  of  the  data  base 
structure  [Ref  15] .  For  an  in  depth  explanation  on 
relational  data  base  design,  please  refer  to  [Ref.  14], 
[Ref.  16]  and  [Ref.  17]  .  Comments  on  the  relational  data 
base  design  as  they  pertain  to  the  Postprocessor  are 
provided  below. 

The  JTLS  Postprocessor  User  Guide  [Ref.  4],  Data 
Requirements  Manual  [Ref.  13],  and  several  sets  of  actual 
game  data  were  used  to  construct  the  design.  Our  initial 
inspection  of  the  JTLS  User  Guide  [Ref.  18]  and  the  game  data 
revealed  a  number  of  irregularities  and  discrepancies.  We 
did  not  attempt  to  improve  or  add  to  the  tables  but  only  to 
translate  the  narrative  data  available  in  the  tables  into  a 
relational  design  format. 

Comments  on  Relational  Design: 


Attributes  are  provided  in  the  order  they  are  produced 
by  the  game.  During  the  logical  design  process  order 
is  normally  unimportant,  however  attributes  are 

8rovided  in  the  order  they  are  produced  by  the  game. 

rder  is  included  in  this  design,  because  it  would 
have  been  impossible  to  construct  the  Push  and  Pull 
programs  without  it.  Only  after  thoroughly  analyzing 
several  sets  of  game  data  could  this  determination  be 
made  as  no  source  documentation  is  available. 


2)  There  is  a  considerable  amount  of  redundancy  in  the 
Postprocessor  tables.  Data  items  are  included  in  a 
table  even  though  they  could  be  determined  through 
some  other  table.  The  redundancy  in  the  Postprocessor 
database  is  intended  to  speed  query  processing  [Ref. 


IX.  RESULT  OF  THE  STUDY 


A.  INTRODUCTION 

This  thesis  supports  the  Naval  Postgraduate  School's 
(NPS)  interest  in  the  study  of  the  feasibility  of  improving 
the  performance  of  JTLS  by  developing  a  method  eliminating 
the  Postprocessor.  We  recommend  the  use  of  a  dedicated 
database  system  running  on  a  separate  machine,  physically  and 
logically  interfaced  to  the  VAX-11.  The  intent  of  this 
project  was  to  determine  the  feasibility  of  improving  the 
performance  of  JTLS  by  eliminating  the  Postprocessor.  To 
this  end,  several  software  products  were  produced. 

The  NPS  made  available  the  VAX-11  complete  with  JTLS, 
the  Sun  Workstation,  and  the  Sun  microsystems'  version  of 
UNIX.  The  Postprocessor  was  neither  examined  nor  executed 
because  it  was  never  available  for  our  use.  The  choice  of 
these  specific  hardware  and  software  components  was 
discussed  in  detail  in  Chapter  1.  However,  the  primary 
reason  remains  that  these  items  continue  to  support  a  wide 
variety  of  possible  modifications  which  are  seriously  being 
contemplated  to  further  enhance  the  performance  of  JTLS,  to 
include  a  distributed  gaming  system  scenario.  As  such,  it 
was  the  goal  of  this  thesis  to  define  the  boundaries  of  one 
small  aspect  of  such  a  problem,  and  in  turn  develop  as  many 
deliverable  products  as  possible  in  fulfillment  of  this 
goal . 

B.  SYNOPSIS 

These  programs  were  developed  to  simulate  the  data 
transmission  from  the  VAX  and  the  assimilation  of  the 
transmitted  data  into  a  JTLS  database  located  on  the  Sun. 
The  first  product  produced  was  the  Push  program.  This 
algorithm  mimics  what  is  anticipated  to  be  the  function  of 
the  modified  CEP.  This  modification  will  involve  the 


creation  of  an  interface  between  the  game  and  the  Ethernet. 
Next,  a  receiving  algorithm  had  to  be  constructed  which 
interfaced  the  Sun  with  the  Ethernet.  Finally,  a  program 
was  developed  which  places  the  data  into  their  respective 
database  table. 

The  tables,  which  are  accessed  by  the  Pack  program,  have 
been  scrutinized  for  possible  points  of  improvement  within 
the  constraints  as  outlined  in  Chapter  1.  After  closely 
reviewing  the  written  goals  detailed  by  the  proponents  of 
JTLS,  we  determined  that  the  tables  will  be  left  in  their 
current  configuration.  However,  no  supporting  documents  for 
the  construction  of  the  tables  could  be  found  anywhere. 
This  required  that  we  design  and  develop  the  Relational 
Design  from  the  available  tables. 

These  database  tables  will  need  to  be  generated  by  the 
ORACLE  database  system.  Once  installed  on  the  Sun,  ORACLE 
must  be  initialized  and  configured  to  communicate  with  the 
Pack  program.  In  this  way  input  data  will  be  accepted  by 
ORACLE  via  a  logical  pipeline  versus  input  generated  from  a 
keyboard. 

To  transport  the  data  from  the  game  to  the  ORACLE 
database  system,  the  Sun  Workstation  will  need  to  be 
included  in  the  local  area  network  (LAN)  as  configured  in  „ 
the  war  laboratory.  This  will  necessitate  that  both  the 
software  and  hardware  installation  take  place  as  prescribed 
in  the  ORACLE  technical  manual .  Not  only  is  the  Ethernet 
required,  but  also  TCP/IP  to  permit  the  VAX  to  conduct  its 
unidirectional  data  traffic. 

C.  ACCOMPLISHMENTS  AND  ANALYSIS 

1 .  Push  Program 

The  Push  program  has  been  completed  and  partially 
tested.  Because  there  is  not  an  internet  connection  between 
the  VAX-11  and  the  Sun  Workstation  at  this  time,  we  can  not 
prove  conclusively  that  the  data  sent  by  the  Push  program 
will  be  received  on  the  Sun  as  we  anticipate.  By  including 


I 

i 

several  debug  statements  throughout  the  program,  the 
program  executes  the  algorithm  as  outlined  in  Chapter  6.  In 
the  testing  phase,  the  program  was  allowed  to  read  several  of 
the  game  files.  It  then  performed  the  necessary  processing 

'  to  the  read  data  and  wrote  the  results  into  a  file  called 

! 

!  GAME.DAT  for  our  review.  Without  error,  the  data  records 

!  had  been  selected,  sorted  and  entered  into  the  file  in  the 

1  correct  time  sequence.  When  more  than  one  record  had  the 

same  time  stamp,  the  program  took  the  first  available  record 
of  that  sequence  and  placed  it  into  GAME.DAT.  After 
fourteen  different  runs,  the  file  GAME.DAT  contained  the 
exact  same  results . 

2 .  Pull  Program 

The  network  interface  aspects  of  the  Pull  program 
could  not  be  tested,  again  because  of  the  lack  of  the 
network  facilities  for  the  Sun.  Though  the  program 
interacted  correctly  with  the  Pack  program,  no  determination 
was  made  concerning  its  ability  to  interface  with  either  the 
data  generated  by  the  Push  program  or  the  Ethernet. 

Inconclusive  testing  of  the  Pull  program  was 
conducted  by  having  the  program  read  a  static  file  titled 
GAME.DAT  which  resided  on  the  Sun  Workstation.  Running  in 
the  background  mode,  the  Pull  program  simulated  data 

acceptance  from  the  Push  program.  No  artificial 

restrictions  were  imposed  on  how  the  Pull  program  read  this 
file.  The  algorithm  specified  that  it  could  read  only  one 
data  item  at  a  time,  and  must  write  that  item  into  either 
GAME 1 . DAT  or  GAME2.DAT  depending  on  the  status  of  the 
respective  RLCK.  By  manually  setting  RLCK  of  the  respective 
files  to  1  or  0,  we  were  able  to  test  whether  the  Pull 
program  would  respond  correctly.  Without  error,  the  Pull 
program  placed  each  data  item  into  the  correct  file  after 
determining  that  the  other  file  RLCK  had  been  set  to  1. 

To  test  the  programs  as  exhaustively  as  possible, 
several  boundary  cases  were  also  examined.  Because  of  the 
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construction  of  the  algorithm,  when  both  files  were  set  to 
1,  it  had  no  impact  on  the  program.  Since  the  program 
alternates  writing  to  each  file,  it  simply  entered  a  busy 
wait  state  until  the  file  it  is  waiting  to  write  into  is 
available.  The  program  will  not  check  the  status  of  the 
other  file  until  it  has  completed  its  write  requirement  to 
the  first  file.  When  both  files  have  RLCK  equal  to  0,  it 
again  has  no  impact  on  the  program.  The  Pull  program  will 
continue  to  write  in  the  same  file  until  a  query  access 
changes  that  RLCK  from  0  to  1 . 

3 .  Pack  Program 

The  Pack  program  and  its  interaction  with  the  Pull 
program  was  extensively  tested  utilizing  the  two  files 
GAME1.DAT  and  GAME2.DAT.  The  Pull  program  was  run  in  the 
background  mode  and  the  Pack  program  in  the  foreground  mode. 
No  resting  of  the  interface  between  the  Pack  program  and 
ORACLE  was  possible  at  this  time. 

Though  we  are  unable  to  verify  the  correctness  of  the 
compatibility  of  the  Pack  program  with  ORACLE,  the  results  of 
the  test  involving  the  Pull  program  lends  substantial 
credibility  to  the  performance  of  the  Pack  program  as 
outlined  in  Chapter  6. 

Once  the  Pull  program  deposits  its  data  into  either 
GAME1.DAT  or  GAME2.DAT,  the  Pack  program  will  be  able  to 
retrieve  the  data  in  the  order  the  Push  program  sent  them 
across  the  network.  By  running  the  Pack  program  in  the 
foreground  mode,  we  were  able,  with  the  aid  of  debug 
write-lines,  to  observe  the  program  read  each  data  entry  and 
place  the  processed  data  into  its  proper  attribute  location. 
Because  there  was  no  database  system  to  generate  the 
initially  empty  tables,  we  are  unable  to  prove  beyond  doubt 
if  the  format  of  the  files  are  compatible  with  ORACLE. 
However,  the  ATTR  data  string  was  successfully  parsed  and 
each  attribute  item  was  received  at  its  designated 
destination  during  testing. 


Several  boundary  cases  were  examined  to  include 

1)  both  files  having  their  WLCK  set  to  1, 

2)  both  files  having  their  RLCK  set  to  0, 

3)  both  files  starting  empty  and  finally, 

4)  the  Pack  program  reading  the  last  data  item 
supplied  by  the  Pull  program. 

All  of  these  cases  were  handled  without  difficulty  by  the 
Pack  program.  If  a  string  did  not  conform  to  the  format  we 
anticipated  in  the  algorithm,  the  program  has  been  designed 
to  discard  that  string. 

Concurrency  control  closely  resembles  the  mutual 
exclusion  problems  which  were  a  major  area  of  research  a  few 
years  ago  [Ref-  17].  However,  these  two  methods  of  time 
control  differ  in  very  subtle  ways.  In  mutual  exclusion  we 
approach  the  problem  from  the  program  side,  establishing 
critical  sections  and  making  sure  no  two  critical  sections 
are  active  at  the  same  time.  In  concurrency  control  we  make 
use  of  the  lock  variables  RLCK  and  WLCK,  approaching  the 
problem  from  the  data  side,  directly  protecting  each  file, 
without  regard  to  which  piece  of  the  program  text  is 
currently  executing.  When  there  are  potentially  many 
programs,  such  as  Pull  and  Pack,  that  might  access  some  of 
the  same  files,  it  makes  more  sense  to  put  the  access 
controls  on  the  files,  rather  than  in  the  programs.  The 
implementation  of  the  locks  is  also  different  because  keeping 
a  semaphore  for  each  file  on  the  file  system  for  the 
unlikely  event  that  someone  might  want  to  lock  it  is  too 
expensive . 

Automatic  locking  is  often  combined  with  atomic 
update  in  a  form  known  as  a  transaction.  In  our  algorithm 
the  form  of  the  transaction  has  been  slightly  modified,  but 
the  principle  is  the  same.  By  definition  a  completed 
transaction  includes  the  property  of  either  running 
successfully  to  completion,  or  failing  and  leaving  the 
system  state  unchanged.  To  run  a  transaction,  one  of  the 
program  locks  the  file  that  it  is  to  use  and  blocks  the 


other  process  from  access.  It  can  then  read  and  write  to 
that  file.  Before  it  is  finished  and  the  process  releases 
the  lock  on  the  file,  the  process  ensures  that  all  changes 
have  been  permanently  made  to  the  file  in  a  single  atomic 
update.  Until  the  changes  are  completed,  no  other  process  is 
able  to  see  or  access  the  file. 

4 .  Relational  Design 

The  JTLS  tables  described  in  the  Postprocessor 
contained  very  little  information  on  attribute  order.  A 
lengthy  analysis  and  comparison  of  every  CEP  produced  file, 
the  Postprocessor  User  Guide  [Ref.  4]  and  the  Data 

Requirements _ Manual  [Ref.  13]  were  necessary  for  the 

development  of  the  Relational  Database  Design  located  in 
Appendix  J.  This  process  was  extremely  tedious  and  time 
consuming,  but  vital  for  the  creation  of  the  JTLS  tables  in 
the  ORACLE  DBMS  and  for  the  processing  of  the  data  through 
the  Pack  program.  The  Relational  Database  Design  will  save 
a  substantial  amount  of  time  and  effort  in  the  continuation 
of  this  project. 

D.  PROJECTED  IMPACT  ON  JTLS 

As  mentioned  earlier,  JTLS  is  a  valid  simulation 
offering  a  host  of  advantages  usually  outlined  in  literature 
such  are  [Ref.  1,2,3]  over  training  exercises  and  actual 
combat.  As  with  most  things,  minor  improvements  in 
appropriate  areas  may  enhance  the  benefits  of  playing  JTLS. 

One  such  improvement  is  the  implementation  of  a 
dedicated  database  management  system  which  will  run 
concurrently  with  the  game.  Although  actual  real-time 
analysis  of  gaming  data  by  a  sequentially  executed  program 
is  virtually  impossible  [Ref.  17],  getting  as  close  as 
possible  is  the  aim  of  this  project. 

The  completion  of  the  Relational  Model  allows  for  a  more 
thorough  analysis  of  all  the  database  table  requirements 
pertinent  to  this  game.  The  developers  of  the  Postprocessor 
have  claimed  that  extensive  attribute  redundancy  was  a 
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necessity  to  accommodate  rapid  data  retrieval.  With  the 
addition  of  the  ORACLE  DBMS,  this  statement  may  need  to  be 
re-examined.  This  later  version  of  the  database  system 
contains  many  dramatic  improvements  over  the  1970's  era 
DBMS'  in  the  realm  of  speed  and  efficiency  [Ref.  19] . 

The  ultimate  impact  of  this  project  on  the  future  of 
JTLS  is  almost  unlimited.  Currently  only  a  single  central 
computer  system  is  able  to  execute  the  game  with  several 
dummy  terminals  available  for  the  players  to  enter  their 
input.  With  the  success  of  the  LAN  and  the  incorporation  of 
a  concurrently  running  data  analysis  capability,  this  system 
is  placed  one  step  closer  to  a  truly  distributed  war  game 
with  major  force  component  players  dispersed  over  many 
miles . 

To  to  keep  this  project  within  reasonable  bounds,  the 
proposal  suggested  the  possibility  of  internetting  only  one 
Sun  Workstation  and  a  demonstration  was  to  take  place 
implementing  this  arrangement.  However,  it  is  obvious  that 
a  minimum  of  two  such  stations  would  need  to  be  in  place  for 
query  activity  to  take  place  for  both  sides  of  a  two-sided 


combat  situation.  The  number  of  Sun  Workstations  need  not 


be  restricted  to  the  number  of  opponents,  but  rather  to  the 
number  of  MIPs  involved  in  any  single  game.  Then  each 
player  would  have  a  dedicated  source  of  information  to 
support  his  decisions. 


E.  CONCLUSION 


If  it  can  be  assumed  that  the  developed  programs 
satisfy  their  performance  requirements,  then  it  is  possible 
to  make  several  conclusions  about  the  outcome  of  this 


feasibility  test: 


1)  It  is  possible  to  use  a  dedicated  processor  for 

off-line  retrieval  of  data  from  an  operational  system. 


2)  The  inclusion  of  a  Sun  Workstation  into  the  Ethernet 
will  allow  very  close  to  real-time  retrieval  of 
pertinent  data,  in  response  to  user  SQL  queries. 
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F.  RECOMMENDATION 


After  close  review  of  the  completed  products  of  this 
thesis,  in  conjunction  with  several  conversations  with  those 
parties  interested  in  JTLS,  we  recommend  that  a  final 
attempt  be  made  to  actually  internet  Sun  Workstations  to  the 
Ethernet  for  the  exchange  of  game  data.  This  is  one  part  of 
the  proposal  that  was  not  completed  in  terms  of  the  actual 
conveyance  of  data  from  one  computer  system  to  another. 
Once  the  data  is  made  available  on  the  Sun,  the  ORACLE 
Technical  Manual  discusses  the  procedure  to  assimilate  data 
received  from  a  communications  channel  into  the  respective 
tables . 


G.  AREAS  FOR  FURTHER  STUDY 

Essentially  there  remain  only  two  major  areas  of 
additional  research  required  to  complete  this  project  within 
the  scope  and  constraints  outlined  in  this  proposal.  These 
include : 

1)  JTLS  CODE  MODIFICATION  -  For  us,  the  SIMSCRIPT  code 
for  JTLS  was  not  made  available  for  review.  A 
thorough  and  indepth  study  should  be  made  on  the 
practicality  and  the  cost-benefits  of  modifying  the 
algorithm  to  make  it  network  compatible.  Particular 
attention  needs  to  be  placed  on  that  part  of  the  code 
that  involves  the  interface  of  the  CEP  to  the  Ethernet. 

2)  MENU  DRIVEN  QUERY  -  It  is  recommended  that  the  menu 
driven  interface  be  translated  directly  from  the 
INGRES-based  language  to  SQL*C.  Though  not  difficult 
to  implement,  it  is  anticipated  to  be  considerably 
large  in  scope.  The  menu  driven  queries  appears  well 
suited  for  command  and  control  queries.  Finally  this 
will  preclude  the  user  from  unnecessarily  learning 
another  aspect  of  an  environment  he  may  already 
consider  hostile  and  unfriendly. 

In  conclusion,  as  a  result  of  the  comprehensive  analysis 
of  the  problem  and  the  development  of  the  software  programs 
and  database  designs,  we  are  confident  that  the  goal  of  this 
project  is  attainable.  Those  areas  recommended  for  further 
actions  should  be  pursued.  We  believe  that  the  continuation 
of  this  project  will  produce  the  desired  result. 


APPENDIX  A 
PROGRAM  FILES 

ACAVAIL.DAT:  JTLS  file  containing  records  on  the  number 
of  aircraft  available  for  launch. 

ACAVAIL.SQL:  Actual  ORACLE  database  containing  the  data 
from  ACAVAIL.DAT.  Data  is  written  to  this  file  in  the 
PACK  program. 

ACAVTM.DAT:  Created  by  the  PUSH  program.  Contains  the 
TIME  attribute  of  the  records  from  ACAVAIL.DAT. 

ACKILLED.DAT:  JTLS  file  containing  records  of  the  number 
of  aircraft  killed. 

ACKILLED . SQL:  Actual  ORACLE  database  containing  the  data 
from  ACKILLED.DAT.  Data  is  written  to  this  file  in  the 
PACK  program. 

ACKLLTM.DAT:  Created  by  the  PUSH  program.  Contains  the 
TIME  attribute  of  the  records  from  ACKILLED.DAT 

ACLAUNCH.DAT:  JTLS  file  containing  records  of  the  number 
of  aircraft  launched  on  missions. 

ACLAUNCH . SQL :  Actual  ORACLE  database  containing  the  data 
from  ACLAUNCH.DAT.  Data  is  written  to  this  file  in  the 
PACK  program. 

ACLAUTM.DAT:  Created  by  the  PUSH  program.  Contains  the 
TIME  attribute  of  the  records  from  ACLAUNCH.DAT. 

ACREM.DAT:  JTLS  file  containing  records  on  the  number  of 
aircraft  on  hand. 

ACREM.SQL:  Actual  ORACLE  database  containing  the  data 
from  ACREM.DAT.  Data  is  written  to  this  file  in  the  PACK 
program. 

ACRETM.DAT:  Created  by  the  PUSH  program.  Contains  the 
TIME  attribute  of  the  records  from  ACREM.DAT. 

GAME . DAT :  Created  by  the  PUSH  program.  This  file  is  used 
to  push  data  across  the  network.  Created  and  written  to 
in  the  PUSH  program  and  read  from  in  the  PULL  program. 

GAME 1 . DAT  &  GAME 2 . DAT :  Created  by  the  PULL  program.  Data 
read  from  the  PULL  program  is  written  to  these  files  to 
be  read  by  the  PACK  program.  Two  files  are  required  to 
enable  the  PACK  program  to  access  data  without 
interfering  with  the  transmission  of  data  across  the 
network . 


APPENDIX  B 

PUSH  PROGRAM  VARIABLES 

CLKINC  (CLOCK  INCREMENT) 

description:  Real  constant  containing  the  value 
(".OOOuOl")  to  increment  the  simulated  game  clock. 

utilization:  Increments  simulated  game  clock  in 
subroutine  CHCLK. 

CTME  (CHARACTER  TIME) 

description:  Character  variable  containing  the 
characters  in  the  time  attribute  of  data  records. 

utilization:  Assigned  the  characters  value  of  the  time 
attribute  in  subroutine  GETIME. 

CUNIT  (CHARACTER  UNIT) 

description:  Character  variable  containing  the 
character  representation  of  the  logical  unit  assigned 
to  a  data  file  on  the  Sun  Workstation. 

utilization:  Determined  and  attached  to  the  data 
record  subroutine  SNDREC.  The  value  of  CUNIT  is  used  by 
the  PACK  program  to  determine  which  table  to  write 
record. 

DELIM  (DELIMITER) 

description:  Character  constant  containing  the  value 
.  Attribute  in  JTLS  records  are  separated  by  the 
ampersand. 

utilization : 

1)  Determines  when  the  last  character  of  the  time 
attribute  has  been  located  in  subroutine  GETIME. 

2)  Attached  to  the  data  record  and  sent  across  the 
network  in  subroutine  SNDREC. 

EFILES  (EMPTY  FILES) 

description:  Integer  variable  that  contains  the  number 
of  closed  files. 

utilization:  (COMMON  /BLK1/) 

1)  Determines  terminal  condition  in  MAIN  program. 

When  EFILES  equals  FILES  program  execution  terminates. 


When  EFILES  equals  FILES  program  execution  terminates 
2)  Incremented  in  subroutine  COMPACT. 


FILES 


description:  Integer  constant  containing  the  number  of 
JTLS  input  files  used  in  this  program. 

utilization:  Used  to  initialize  OFILES  in  main 
program. 
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GMCLK  (GAME  CLOCK) 

description : Real  variable  simulating  the  JTLS  game 
time. 

utilization: (COMMON  /BLK2/) Determines  when  data  is 
sent  in  subroutine  SND . 

INDEX 

description:  Integer  variable  containing  the  value  of 
the  index/position  of  the  array  TMARY . 

utilization:  (COMMON  /BLK3/) 

1)  Increments  the  position  of  the  arrays  TMARY 

and  UTARY  during  initialization  in  subroutine  IARAYS. 

2)  Indicates  what  position  of  the  array  TMARY  to 
place  data  in  subroutine  RDTME . 

INFO 

description:  Character  variable  containing  the 
characters  of  the  file  identifier  and  the  data  record. 

utilization:  Created  and  sent  across  the  network  in 
subroutine  SNDREC. 


I TEMP  (INTEGER  TEMPORARY) 

description:  Integer  variable  containing  the  value  of 
an  UTARY  array  element. 

utilization:  Used  as  temporary  storage  for  the  elements 
of  array  UTARY  in  subroutine  SORT. 

LENGTH 

description:  Integer  variable  containing  the  number  of 
characters  in  a  time  attribute. 

utilizations:  Determines  the  number  of  character 
concatenations  required  in  subroutine  GETIME . 

MAXPOS  (MAXIMUM  POSITION) 

description:  Integer  constant  containing  the  maximum 
number  of  characters  in  a  record  ("IS")  required  to 
extract  the  time  attribute. 

utilization;  Test  if  time  attribute  has  too  many 
characters  m  subroutine  GETIME. 

MINLEN  (MINIMUM  LENGTH) 

description:  Integer  constant  containing  the  minimum 
number  of  characters  required  ("2”)  in  a  time 
attribute. 

utilization:  Test  if  time  attribute  has  enough 
characters  in  subroutine  GETIME. 

MORE 

description:  Logical  variable, 
utilization : 
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1)  Terminates  string  comparison  in  subroutine  GETIME. 

2)  Terminates  sort  in  subroutine  SORT. 

3)  Terminates  clock  increment  in  subroutine  CKCLK. 
OFILES  (OPEN  FILES) 

description:  Integer  variable  containing  the  number  of 
data/time  files  that  are  open. 

utilization:  (COMMON  /BLK4/) 

1)  Determines  if  sorting  is  required  in  MAIN  program 
(Sorting  is  unnecessary,  if  one  file  is  open) . 

2)  Provides  subroutine  SORT  with  the  number  of 
elements,  of  the  array  TMARY,  to  be  compared. 

3)  Decremented  in  subroutine  COMPACT. 

POSIT  (POSITION) 

description:  Integer  variable  containing  the  value 
of  the  index  of  tne  character  array  STRING. 

utilization:  Positions  the  index  for  character  array 
STRING,  to  determine  the  length  of  the  time  attribute 
in  subroutine  GETIME. 

RECORD 

description:  Character  variable  containing  the 
characters  of  a  data  file  record. 

utilization:  Assigned  the  characters  of  the  data 
record  and  attached  to  a  file  identifier  in  subroutine 
SNDREC . 

RTEMP  (REAL  TEMPORARY) 

description:  Real  variable  containing  the  value  of  a 
TMARY  array  element. 

utilization:  Used  as  temporary  storage  for  the  elements 
of  array  TMARY  in  subroutine  SORT. 

RTME  (REAL  TIME) 


description:  Real  variable  containing  the  time 
attribute  of  a  data  record  in  decimal  days . 

utilization:  Decoded  from  the  character  variable  CTME 
and  written  to  a  time  file  in  subroutine  GETIME. 

STRING 

description:  Character  array  containing  the  first 
thirteen  characters  of  a  data  record. 

utilization:  The  first  thirteen  characters  of  a  data 
record  are  read  into  STRING.  This  enables  the 
extraction  of  the  time  attribute  in  subroutine  GETIME. 

SRTPOS  (START  POSITION) 

description:  Integer  constant  containing  the  starting 
position  ("3")  of  the  characters  in  the  time  attribute 
of  JTLS  data  records . 
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utilization:  Initializes  POSIT  in  subroutine  GETIME. 
TMARY  (TIME  ARRAY) 

description:  Real  array  that  contains  a  record  from 
each  or  the  open  time  riles. 

utilization:  (COMMON  /BLK7 / ) 

1)  TMARY  (INDEX)  is  assigned  the  value  of  the 
appropriate  time  file  in  subroutine  RDTME . 

2)  Elements  are  compared  and  interchanged  if 
necessary  in  subroutine  SORT. 

3)  The  first  element  of  array  TMARY  (the  time  to 
send  the  next  record)  is  compared  with  GMCLK  to 
determine  when  the  record  will  be  sent  in  subroutine 
CKCLK . 

4)  Adjusted  by  shifting  all  elements  to  theleft  in 
subroutine  COMPACT. 

UNT  (UNIT) 

description:  Integer  variable  containing  the  value  of 
the  logical  units  of  the  data  or  time  files. 

utilization:  (COMMON  /BLK6/ ) 

1)  Used  as  counter  in  subroutine  IFILES  for  creating 
time  files. 

2)  The  value  of  the  logical  data  file  unit  to  be  read 
in  subroutine  GETIME. 

3)  Determines  the  value  ("UNT+1")  of  the  logical 
time  file  unit  in  subroutine  GETIME. 

4)  Used  as  counter  in  subroutine  IARAYS  for 
initiating  the  arrays  TMARY  and  UTARY. 

5)  Contains  the  value  of  the  logical  time  file 
unit  read  in  subroutine  RDTME. 

6)  Contains  the  value  of  the  logical  time  file 
unit  to  be  closed  in  subroutine  COMPACT. 

7)  Assigned  the  value  of  the  array  UTARY  element 
INDEX  (first  array  element)  in  MAIN  program. 

8)  Determines  the  value  ("UNT-1")  of  the  logical 
data  file  unit  of  the  data  record  to  be  read 

and  sent  across  the  network  in  subroutine  SNDREC. 

UTARY  (UNIT  ARRAY) 

desgription:  Integer  array  containing  the  values  of 
logical  time  files  unit  numbers. 

utilization:  (COMMON  /BLK7/) 

1)  Initialized  in  subroutine  IARAYS. 

2)  The  elements  are  interchanged  as  TMARY  elements  are 
interchanged  in  subroutine  SORT. 

3)  Adjusted  by  shifting  all  elements  to  the  left  in 
subroutine  COMPACT.  (The  value  in  the  first  element  is 
the  unit  being  closed) . 
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APPENDIX  C 
PROGRAM  PUSH  CODE 

PROGRAM  PUSH 

INTEGER  EFILES, FILES, INDEX, OFILES, UNT, UTARY (45) 

REAL  GMCLK, TMARY (45) 

COMMON  /BLKl/EFILES, /BLK2/GMCLK, /BLK3/INDEX, /BLK4 /OFILES 

COMMON  / BLK5 / TMARY , / BLK6 / UNT , /BLK7 /UTARY 

DATA  EFILES, FILES, GMCLK, INDEX, TMARY/0, 4, 0. 0, 1, 45*0.0/ 

OFILES-FILES 

CALL  IFILES 

CALL  IARAYS 

INDEX— 1 

PRINT*,  ' SORTING  AND  SENDING  DATA' 

DO  WHILE (EFILES. NE. FILES) 

IF (OFILES. GT.l) CALL  SORT 
UNT-UTARY (INDEX) 

CALL  CHCLK 
CALL  RDTME 
END  DO 
CLOSE  UNIT-7 
CLOSE  UNIT=10 
CLOSE  UNIT— 12 
CLOSE  UNIT-14 
CLOSE  UNIT— 16 

PRINT*,  'PROGRAM  COMPLETED' 

STOP 

END 

************************************************************ 
SUBROUTINE  IFILES 
INTEGER  UNT 
COMMON  /BLK6/UNT 
PRINT*. 'OPENING  FILES' 

OPEN  (UNIT— 7  .FILE-'  GAME  .  DAT'  ,  STATUS-'  NEW'  ) 

OPEN  UN I T= 1 0 , F I LE— ' ACAVAI L . DAT , STATUS-OLD ' ) 

OPEN (UNIT-11,  FILE-' ACAVTM.DAT' .STATUS— ' NEW' ) 

OPEN (UNIT-12,  FILE-' ACKILLED.DAT, STATUS-OLD' ) 

OPEN (UNIT— 13, FILE—' ACKLLTM . DAT' , STATUS—' NEW' ) 

OP  EN ( UN I T= 1 4 , F I LE- ' ACLAUNCH . DAT , STATUS-OLD ' ) 

OP  EN ( UN I T- 1 5 , F I LE- ' ACLAUTM . DAT ' , STATUS- ' NEW  * ) 

OPEN ( UNIT-1 6, FILE-' ACREM. DAT, STATUS-OLD' ) 

OPEN ( UN IT-1 7, FILE- 'ACRETM.DAT' , STATUS-' NEW' ) 

PRINT*. 'CREATING  TIME  FILES' 

DO  10  UNT— 10,16,2 
CALL  GETIME 
REWIND  UNT 
REWIND  (UNT+1 ) 

10  CONTINUE 

PRINT*, 'FINISH  CREATING  TIME  FILES' 

RETURN 

END 

************************************************************ 
SUBROUTINE  GETIME 

INTEGER  LENGTH, MAXP OS, MI NLEN, POSIT, SRTPOS, UNT 
REAL  RTME 

CHARACTER* 10  CTME, DELIM*1,  STRING (13) *1 
LOGICAL  MORE 
COMMON  /BLK6/UNT 

DATA  DELIM, MAXPOS. MINLEN, SRTPOS/' &'  ,  13,2,3/ 

10  READ(UNT, 100, END-103, ERR-102 ) STRING ( I ) ,1=1, MAXPOS 
100  FORMAT (1 5a1) 

MORE- . TRUE . 

POSIT-SRTPOS 

LENGTH-0 
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DO  WHILE (MORE) 

IF  ( STRING (POSIT)  . EQ . DELIM) THEN 
MORE- . FALSE . 

ELSE 

IF (LENGTH . EQ . MAXPOS . AND . STRING (POSIT) . NE . 
DELIM) THEN 

PRINT* ."TIME  IS  GREATER  THAN  F10.6 
FORMAT'' 

GO  TO  103 
END  IF 

LENGTH-LENGTH+ 1 
POSIT=POSIT+l 

END  IF 
END  DO 

IF  ( LENGTH.LT. MI NLEN) THEN 

PRINT*. "TIME  IS  ONLY  ONE  CHARACTER” 

GO  TO  103 

END  IF 

IF ( LENGTH . EQ . 2 ) CTME-STRING ( 3 ) / /STRING ( 4 ) 

IF ( LENGTH . EQ . 3 ) CTME-STRING ( 3 ) //STRING  4) //STRING (5) 
IFiLENGTH.EQ. 4) CTME-STRING (3) //STRING (4) //STRING (5) 

L  7 / STRING ( 6 ) 

IF (LENGTH . EQ . 5 ) CTME-STRING ( 3 ) / / STRING ( 4 ) / /STRING ( 5 ) 

L //STRING (6) //STRING (7) 

IF ( LENGTH. EQ. 6) CTME-STRING (3) //STRING (4) //STRING (5) 


_  _ . _ / /STRING  (5) 

CTME-STRING (3) //STRING (4) //STRING (5) 

CTME=STRING (3) //STRING (4 ) //STRING (5) 
RING ( 7 ) 

CTME-STRING ( 3 ) //STRING (4) //STRING (5) 
RING(7£//STRING(8) 

CTME-STRING (3) //STRING (4) //STRING (5) 
RING (7) //STRING (8) //STRING (9) 
CTME-STRING (3) //STRING (4) //STRING (5) 
RING (7)7  7 STRING (8)  //STRING  (9£//STRIti 


1//S 

i  m 


1/ /String (6) ^/s^ring (7) //string  ( 
IF (LENGTH . EQ . 8 ) CTME=STRING ( 3 ) // 
1//STRING (6) //STRING (7) //STRING ( 
IF (LENGTH . EQ . 9 ) CTME=STRING( 3 ) // 
1//STRING (6) //STRING (7) //STRING ( 
1//STRING (10) //STRING (11) 

IF ( LENGTH. EQ. 10) CTME=STRING (3) // 
1/ /STRING (6f/ /STRING (7) //STRING ( 
1/ /STRING (l0) //STRING (11) //STRIN 
DECODE ( LENGTH ,101, CTME ) RTME 


RING (3) //STRING (4) //STRING (5) 
//STRING (8) //STRING (9) 

RING (3) //STRING (4) //STRING (5) 
//STRING (8) //STRING (9) //STRING (10) 

-  '/string (4) 7/st - 


ft.EQ.9)CTME=STRING(3)  //STRING  (4)  //STRING  (5) 
( 6 ) 7 /STRING <7 ) / / STRING ( 8 ) / 7  STRING ( 9 ) 

(10)  //STRING  i'll) 

.EQ.10)CTME=STRING(3) //STRING (4) //STRING (5) 
(6)7/STRING(7) //STRING (8) //STRING (9) 


DECODE ( LENGTH ,101, CTME )  1 
WRITE ( (UNT+1 ) , 101) RTME 
FORMAT (F10. 6) 


G(12) 


LINE  7" 


GO  TO  10 
PRINT*, "ERROR 


READING  DATA  FILES  SUBROUTINE  GETIME 


RETURN 


END 

SUBROUTINE  IARAYS 
INTEGER  INDEX, UNT . UTARY (45) 

COMMON  /BLK3 / INDEX , 7BLK6/UNT, /BLK7/UTARY 
DO  10  UNT-11,17,2 
CALL  RDTME 
UTARY ( INDEX) =UNT 
INDEX-INDEX+1 
10  CONTINUE 
RETURN 
END 

*************************************>t********************** 

SUBROUTINE  RDTME 
INTEGER  INDEX, UNT 
REAL  TMARY  <4  5  S 

COMMON  /BLK3/INDEX. /BLK5/TMARY, /BLK6/UNT 
READ (UNT. 100, END-101, ERR-102) TMARY (INDEX) 

100  FORMAT (F10. 6) 

RETURN 

101  CALL  COMPACT 
RETURN 

102  PRINT*, "ERROR  READING  TIME  FILES  IN  SUBROUTINE  RDTME 
1LINE  5" 

RETURN 

END 
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'ILES, /BLK4/0FILES, / BLK5 / TMARY , /BLK6/UNT, 


SUBROUTINE  COMPACT 

INTEGER  EFILES, OF ILES, UNT, UTARY (45) 

REAL  TMARY (45) 

COMMON  BLK1/EF] 

1/BLK7 /UTARY 
J-OFILES-1 
IF (OFILES . GT . 1 ) THEN 
DO  10  1=1, J 

TMARY ( I ) =TMARY ( I  + 1 ) 

UTARY { I ) -UTARY  1+1) 

10  CONTINUE 

END  IF 

EFILES=EFILES+1 

OFILES=OFILES-l 

CLOSE  UNIT-UNT 

PRINT*, ('CLOSED  UNIT', UNT) 

RETURN 

END 

************************************************************ 
SUBROUTINE  SORT 
INTEGER  OFILES, ITEMP, UTARY (45) 

REAL  RTEMP, TMARY (45) 

LOGICAL  MORE 

COMMON  /BLK4/OFILES, / BLK5 / TMARY , /BLK7/UTARY 

J-OFILES-1 

MORE= . TRUE . 

DO  10  1=1, J 

IF ( . NOT . MORE ) RETURN 

K-OFILES-I 

MORE* . FALSE . 

DO  20  L-l.K 

IF (TMARY (L) . GT . TMARY ( L+ 1 )) THEN 
MORE* . TRUE . 

RTEMP -TMARY (L) 

TMARY  (L)  -TMARY  (L+l) 

TMARY (L+l) -RTEMP 
I TEMP -UTARY (L) 

UTARY ( L ) -UTARY ( L+ 1 ) 

UTARY  L+l) -ITEMP 

ENDIF 

20  CONTINUE 

10  CONTINUE 
RETURN 
END 

************************************************************* 
SUBROUTINE  CHCLK 
INTEGER  INDEX 

REAL  CLKINC, GMCLK, TMARY (45) 

LOGICAL  MORE 

COMMON  /BLK2/GMCLK, /BLK3/INDEX, / BLK5 / TMARY 
DATA  CLKINC  / .000001/ 

MORE- . FALSE . 

DO  WHILE (.NOT. MORE) 

IF (TMARY ( INDEX) . EQ . GMCLK) THEN 
CALL  SNDREC 
MORE- . TRUE . 

ELSE 

GMCLK-GMCLK+CLKINC 

ENDIF 
END  DO 
RETURN 
END 

************************************************************* 
SUBROUTINE  SNDREC 
INTEGER  UNT 
CHARACTER* 1  DELIM 

CHARACTER  CUNIT*2, INFO*80, RECORD*77 
COMMON  /BLK6/UNT 
DATA  DELIM  /'&'/ 
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I F  UNT . EQ .11) CUN I T= '10' 

IF  (UNT.EQ. 13) CUNIT=' 11' 

IF  UNT.EQ. 15  CUNIT-' 12' 

IF (UNT.EQ. 17  CUNIT=' 13' 

READUUNT-1)  , 101 , END=103, ERR=1 04 ) RECORD 
FORMAT (A7 7) 

INFO-CUNIT//DELIM/ /RECORD 
WRITE  (7. 102) INFO 
FORMAT  (X, A80) 

RETURN 

PRINT*. "ERROR  READING  DATA  FILE  IN  SUBROUTINE  SNDREC 
1LINE  9" 

RETURN 

END 
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APPENDIX  D 

PROGRAM  PUSH  CODE  DESCRIPTION 


PROGRAM  PUSH 

INTEGER  EFILES .FILES, INDEX, OFILES, UNT, UTARY (45) 

REAL  GMCLK , TMARY (45) 

COMMON  /BLK1/EFILES, /BLK2/GMCLK, /BLK3/INDEX, /BLK4 / OFILES 
COMMON  / BLK5 / TMARY , /BLK6/UNT, /BLK7/UTARY 

Initialization  of  variables. 

DATA  EFILES, FILES, GMCLK, INDEX, UTARY  /0, 4, 0 .0, 1, 45*0 . 0/ 
OFILES=FILES 

Open  data  files  and  create  time  files. 

CALL  IFILES 

Initialize  arrays  TMARY  and  UTARY 
CALL  IARAYS 

Assign  INDEX  the  value  of  "1".  All  subsequent  reads  of  time 
files  will  be  placed  into  the  first  element  of  array 
TMARY.  See  subroutine  RDTME . 

INDEX=1 

End  Initialization. 

PRINT*,  ' SORTING  AND  SENDING  DATA' 

Send  records  while  data  files  are  open.  Terminate  process 
if  all  data  files  are  closed  {The  number  of  empty  riles  is 
equal  to  the  number  of  data  files  used) . 

DO  WHILE (EFILES. NE. FILES) 

Call  subroutine  SORT  if  there  is  more  than  one  file  open. 
Sorting  is  not  required  if  only  one  file  is  open. 

IF (OFILES. GT.l) CALL  SORT 

Assign  the  value  of  the  first  element  of  array  UTARY  to 
UNT. 

The  logical  unit  of  the  next  record  to  be  transmitted  is 
"UNT-1" .  The  logical  unit  of  the  next  time  file  to  be  reads 
is  the  value  "UNT" . 

UNT=UTARY (INDEX) 

Determine  when  data  should  be  sent. 

CALL  CHCLK 

Get  the  next  time  file  record. 

CALL  RDTME 

END  DO 
Close  files. 

CLOSE  UNIT=7 
CLOSE  UNIT=10 
CLOSE  UNIT=12 
CLOSE  UNIT=1 4 
CLOSE  UNIT=1 6 


PRINT*,  'PROGRAM  COMPLETED' 

STOP 

END 

SUBROUTINE  IFILES 

This  subroutine  opens  data  and  time  files.  Logical 
assignments  begin  with  number  10.  The  data  files  are 
assigned  even  units,  and  the  time  files  are  assigned  a 
unit  1  higher  of  it's  respective  data  file  (the  odd 
numbered  units) .  The  routine  then  call  subroutine  GETIME 
to  create  time  files  on  the  appropriate  units. 

INTEGER  UNT 
COMMON  /BLK6/UNT 
PRINT*, 'OPENING  FILES' 

Open  files  and  assign  logical  units. 

"GAME.DAT"  is  used  to  transmit  data  across  the  network. 


OPEN (UNIT-7,  FILE- 
OPEN  (UNIT-10,  FILE 
OPEN (UNIT-11,  FILE 
OPEN (UNIT-12,  FILE 
OPEN  (UNIT-13,  FILE 
OPEN (UNIT-14,  FILE 
OPEN (UNIT-15,  FILE 
OPEN  (UNIT-16,  FILE 
OPEN (UNIT-17,  FILE 
PRINT*, 'CREATING 


•'GAME.DAT'  ,  STATUS-' NEW'  ) 

= ' ACAVAI L . DAT , STATUS-OLD ' ) 
-'ACAVTM.DAT' , STATUS-' NEW' 
- ' ACKI LLED . DAT , STATUS-OLD ' 
-'ACKLLTM.DAT' , STATUS-' NEW 
-'ACLAUNCH.DAT, STATUS-OLD' 
-'ACLAUTM.DAT' , STATUS-' NEW 
-'ACREM.DAT. STATUS-OLD' ) 
-'ACRETM.DAT' , STATUS-' NEW' 
TIME  FILES' 


This  loop  is  for  creating  time  files.  The  loop  control 
variable  "UNT"  determines  the  data  and  time  files  to  be 
read  and  written.  Files  are  rewound  for  subsequent 
processing. 

DO  10  UNT— 10,16,2 
CALL  GETIME 
REWIND  UNT 
REWIND  (UNT+1 ) 

L0  CONTINUE 

PRINT*, 'FINISH  CREATING  TIME  FILES' 

RETURN 

END 


SUBROUTINE  GETIME 

This  routine  extracts,  and  converts  the  characters  of  the 
time  attribute  to  real  format,  and  writes  them  to  a  time 
file . 

Data  analysis  showed: 

1)  the  third  character  of  JTLS  records  is  the  first 
character  of  the  time  attribute  (SRTPOS) . 

2)  the  minimum  number  of  characters  in  the  time 
attribute  is  two  (MINLEN) . 

3)  The  maximun  number  of  characters  in  a  time  attribute 
is  10  . 

4)  Attributes  in  JTLS  records  are  separated  by  the 
delimiter  "&" (DELIM) . 

INTEGER  LENGTH, MAXPOS, MINLEN, POSIT, SRTPOS, UNT 
REAL  RTME 
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CHARACTER* 10  CTME, DELIM*1, STRING (13) *1 
LOGICAL  MORE 
COMMON  /BLK6/UNT 

DATA  DELIM, MAXPOS, MINLEN, SRTPOS/' &' , 13,2,3/ 
c 

c  Read  the  first  thirteen  characters  of  a  record  into  the 
c  character  array  STRING.  The  subroutine  will  return  when  an 
c  end  of  file  is  read, 
c 

10  READ (UNT, 100, END=103, ERR=102) STRING (I) , 1=1, MAXPOS 
100  FORMAT (13A1) 

MORE= . TRUE . 

POSIT=SRTPOS 

LENGTH=0 

c 

c  Determine  the  number  of  characters  in  the  time  attribute, 
c  When  the  delimiter  has  been  read  the  number  of 

c  characters  in  the  time  attribute  is  determined, 
c 

DO  WHILE (MORE) 
c 

c  Check  string  position  for  delimiter, 
c 

IF (STRING (POSIT) . EQ . DELIM) THEN 
MORE= . FALSE . 

ELSE 

c 

c  Check  for  error.  If  the  thirteenth  position  is  checked  and 
c  it  is  not  the  delimiter  an  error  message  will  be  provided, 
c 

IF (LENGTH . EQ .MAXPOS .AND . STRING (POSIT) .NE . 

1  DELIM) THEN 

PRINT*. "TIME  IS  GREATER  THAN  F10.6 
1  FORMAT'' 

GO  TO  103 

END  IF 

c 

c  Increment  length  and  string  position, 
c 

LENGTH=LENGTH+1 

POSIT=POSIT+l 

END  IF 
END  DO 
c 

c  If  length  is  less  than  two  characters  an  error  message  will 
c  result . 
c 

IF  (LENGTH.LT. MINLEN) THEN 

PRINT* ."TIME  IS  ONLY  ONE  CHARACTER" 

GO  TO  103 

END  IF 
c 

c  After  the  number  of  characters  in  the  time  attribute  have 
c  been  determined,  the  following  decision  statements  will 
c  determine 

c  the  appropriate  number  of  concatenations  to  be  made. 

IF (LENGTH . EQ . 2 ) CTME-STRING (3 ) //STRING (4 ) 

IF (LENGTH . EQ. 3  CTME=STRING  3  //STRING  4  //STRING (5) 

IF (LENGTH . EQ . 4  CTME=STRING  3  / / STRING  4  / /STRING  5 
1 7 /STRING (6) 

IF (LENGTH . EQ . 5) CTME=STRING ( 3 ) //STRING ( 4 ) //STRING ( 5 ) 
l7/STRING(61//STRING(7) 


i// String (6)7/ string (7) 

IF7LENGTH.EQ. 6) CTME=STRING (3) / /STRING ( 4 ) //STRING ( 5 ) 
17/STRING  (6T//STRING (7£/7STRING (8) 

IF (LENGTH . EQ . 7 ) CTME=StRING ( 3) //STRING (4) //STRING (5) 
l7/STRING(6) //STRING(7) /7STRING(8) /7sTRING(9) 

IF (LENGTH . EQ . 8 ) CTME=STRING ( 3 ) / /STRING ( 4 ) //STRING ( 5 ) 
l7/STRING(6) //1STRING(7) 7/STRING (8 ) //STRING ( 9) 
1//STRING  10) 
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IF (LENGTH 
1// STRING ( 
1// STRING ( 
IF (LENGTH 


1  /  /  STRING  (10 )//  ST! 

IF (LENGTH. EQ. 10) < 
1//STRING(6T7/STR 

i//string|i6)  //st: 


//STRIN 


CTME=STRING ( 3 ) //STRING (4) //STRING (5) 
ING (7) //STRING (8) //STRING (9) 

RING (11) / /STRING (12) 


c  Convert  the  time  attribute  from  character  to  real,  and 
c  write  it  to  the  appropriate  time  file, 
c 

DECODE (LENGTH, 101, CTME) RTME 


DECODE (LENGTH, 101, CTME 
WRITE (  UNT+1) , 101) RTME 
FORMAT (F10. 6) 


101  FORMAT (F10 . 6) 
c 

c  Control  is  returned  to  statement  10  to  read  the  next  data 
c  file  record. 

GO  TO  10 

102  PRINT*, "ERROR  IN  READING  DATA  FILES  SUBROUTINE  GETIME 
1LINE  7" 

103  RETURN 
END 

************************************************************ 
SUBROUTINE  IARAYS 
c 

c  This  subroutine  is  used  to  initialize  arrays  TMARY  and 
c  UTARY.  The  first  time  record  of  each  time  rile  is  read 
c  into  successive  elements  of  TMARY.  The  elements  of  array 
c  UTARY  contain  the  logical  unit  value  of  the  corresponding 
c  elements  in  array  TMARY. 
c 

INTEGER  INDEX, UNT 
COMMON  /BLK3/INDEX, /BLK6/UNT 
c 

c  The  time  files  are  the  odd  logical  units  beginning  with 
c  unit  "11".  The  first  record  of  each  time  file  is  read  into 
c  successive  elements  of  array  TMARY. 

DO  10  UNT=11, 17, 2 
CALI-  RDTME 
INDEX=INDEX+1 
UTARY ( INDEX) =UNT 
10  CONTINUE 
RETURN 
END 


SUBROUTINE  RDTME 
C 

c  This  routine  is  used  to  read  a  time  record  into  the 
c  appropriate  element  of  TMARY.  If  an  end  of  file  is  read, 
c  subroutine  COMPACT  is  called  to  adjust  the  arrays  and 


c  close  the  empty  file. 

°  INTEGER  INDEX, UNT 
REAL  TMARY (45[ 

COMMON  /BLK3 / INDEX ,/BLK5/ TMARY. /BLK6/UNT 
READ  (UNT.  100,  END*=lul ,  ERR=1 02  )  TMARY  (INDEX) 

100  FORMAT (FlO. 6) 

RETURN 

101  CALL  COMPACT 
RETURN 

102  PRINT*. "ERROR  READING  TIME  FILES  IN  SUBROUTINE  RDTME 
1LINE  5" 

RETURN 

END 

************************************************************* 
SUBROUTINE  COMPACT 
C 

c  This  routine  is  called  when  a  end  of  file  indicator  has 
c  been  read. The  routine  will  shift  elements  of  the  arrays 
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TMARY ,  and  UTARY  to  the  left  writing  over  the  first 
element  of  each  array.  This  is  done  to  reduce  the  number 
of  comparisons  required  in  the  sort  routine. 


INTEGER  EFILES, OFILES, UNT, UTARY (45) 

REAL  TMARY  (45) 

COMMON  /BLK1 /EFILES, /BLK4/0FILES, /BLK5/TMARY, 
1/BLK6/UNT, /BLK7/UTARY 

J=OFILES-l 

Adjustment  is  not  required  if  one  file  is  open. 

IF (OFILES . GT . 1 ) THEN 
DO  10  1=1. J 

TMARY ( I ) =TMARY ( I + 1 ) 

UTARY (I  -UTARY  1  +  1) 

10  CONTINUE 

ENDIF 

Increment  the  number  of  empty  files,  decrement  the  number 
of  open  files,  and  close  the  unit. 

EFILES=EFILES+1 

OFILES=OFILES-l 

CLOSE  UNIT— UNT 

PRINT*, ('CLOSED  UNIT', UNT) 

RETURN 

END 

★A********************************************************* 

SUBROUTINE  SORT 

This  routine  sorts  the  array  TMARY  in  descending  order. 
Interchanges  of  elements  of  TMARY  necessitates  an 
interchange  of  the  corresponding  elements  in  UTARY. 

INTEGER  OFILES, ITEMP, UTARY (45) 

REAL  RTEMP . TMARY (45) 

LOGICAL  MORE 

COMMON  /BLK4 /OFILES, / BLK5 / TMARY , /BLK7/UTARY 

J=OFILES-l 

MORE= . TRUE . 

The  program  will  return  if  an  interchange  is  not  required 
during  any  iteration  of  the  following  loop. 

DO  10  1=1,  J 

IF ( .NOT. MORE) RETURN 

Adjust  the  number  of  required  comparisons. 

K=OFILES-I 
MORE* . FALSE . 

This  loop  places  the  greatest  value  compared  into  array 
element  K.  Upon  completion  of  this  loop  it  is  no  longer 
necessary  to  compare  position  K. 

DO  20  L-1.K 

IF (TMARY (L) . GT . TMARY (L+l) ) THEN 
MORE* . TRUE . 

RTEMP -TMARY (L) 

TMARY (L) -TMARY (L+l) 

TMARY (L+ if -RTEMP 
I TEMP -UTARY (L) 

UTARY (L) -UTARY (L+l ) 

UTARY (L+l) -ITEMP 

ENDIF 

20  CONTINUE 


10  CONTINUE 
RETURN 
END 

A*********************************************************** 

SUBROUTINE  CHCLK 
C 

c  This  routine  determines  when  to  send  data  across  the 
c  network.  A  record  will  be  sent  when  the  record's  time 
c  (contained  in  array  TMARY)  is  equal  to  the  simulated  game 
c  clock.  If  the  record's  time  is  not  equal  to  the  simulated 
c  clock,  the  clock  is  incremented  until  they  are  equal. 

INTEGER  INDEX 

REAL  CLKINC .GMCLK, TMARY (45) 

LOGICAL  MORE 

COMMON  / BLK2 / GMCLK, / BLK3 / I NDEX , /BLK5/TMARY 
DATA  CLKINC  /. 000001/ 

MORE= . FALSE . 

DO  WHILE ( .NOT. MORE) 
c 

c  Compare  record  time  with  game  clock.  Send  record  if  times 
c  are  equal.  Increment  game  clock  if  times  are  not  equal. 

IF (TMARY ( INDEX) . EQ . GMCLK) THEN 
CALL  SNDREC 
MORE= . TRUE . 

ELSE 

GMCLK=GMCLK+ CLKINC 

END  IF 
END  DO 
RETURN 
END 

**********  *************************************************** 
SUBROUTINE  SNDREC 

c 

c  This  routine  reads  a  data  record,  combines  the  record  with 
c  an  identifier  and  writes  the  data  to  the  file  GAME . DAT . 
c  GAME . DAT  is  read  by  the  PULL  program  on  the  Sun 
c  Workstation. 

INTEGER  UNT 
CHARACTER* 1  DELIM 

CHARACTER  CUNIT*2, INFO*80, RECORD*77 
COMMON  /BLK6/UNT 
c 

c  Determine  the  table  identifier  to  be  attached  to  the 
c  record, 
c 


IF  i 

(UNT. EC 

i.H] 

ICUNIT-' 

10' 

IF  i 

UNT. EC 

.i:i 

> CUNIT— ' 

11' 

IF  ■ 

UNT. EC 

.15] 

ICUNIT-' 

12' 

IF 

(UNT. EC 

.17 

1  CUNIT-' 

13' 

c 

c  Read  data  record. 

READ ( (UNT- 1 ) , 101, END-103, ERR-104) RECORD 

101  FORMAT (A77) 
c 

c  Attagh  identifier  to  data  record.  The  delimiter  is  required 
c  to  distinguish  the  identifier  and  the  first  attribute  of 
c  the  record, 
c 

INFO—CUNIT/ /DELIM/ /RECORD 
l.RITE  (7. 102)  INFO 

102  FORMAT  (X, A80) 

103  RETURN 

104  PRINT*, "ERROR  READING  DATA  FILE  IN  SUBROUTINE  SNDREC 
LINE  9" 

RETURN 

END 


APPENDIX  E 


PULL  &  PACK  PROGRAM  VARIABLES 
ANUM  (ATTRIBUTE  NUMBER) 

description:  Integer  variable  containing  the  number  of 
attributes  that  have  been  extracted  from  the  record. 

utilization : 

1)  Determines  how  attributes  obtain  a  value  in 
subroutine  CONVRT . 

2)  Initialized  and  incremented  in  subroutine 
FNDATT . 

ATTR  (ATTRIBUTE) 

description:  Character  variable  containing  the  value  of 
a  record's  attributes. 

utilization : 

1)  Assigned  value  in  subroutine  CONCAN. 

2)  Provides  value  to  the  actual  attribute  in 
subroutine  CONVRT. 

CONFLT  (CONFLICT) 

description:  Integer  variable  containing  the  value  of 
an  actual  table  attribute. 

utilization:  (COMMON  /BLK4 / ) 

1)  Assigned  value  in  subroutine  CONVRT. 

2)  Written  to  table  in  subroutine  ENTTUP . 

DEL  (DELIMITER) 

description:  Charactercontaining  the  attribute 
delimiter 

utilization:  Determines  when  the  last  character  of  an 
attribute  has  been  located  in  subroutine  FNDATT. 


INFO 


description:  Character  variable  containing  the 
information  sent  from  the  VAX-11. 

utilization:  Read  from  VAX  and  written  to  a  data  file 
on  the  Sun  Workstation. 


INX  (INDEX) 


description:  Integer  variable  containing  the 
index/position  of  the  character  array  RCD. 

utilization:  Positions  the  index  of  character  array  RCD 
for  comparison  in  determining  the  length  of  an 
attribute  in  subroutine  FNDATT. 
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INTRVL  (INTERVAL) 

description:  Integer  variable  containing  the  value  of 
an  actual  table  attribute. 

utilization:  (COMMON  /BLK2 / ) 

1)  Assigned  value  in  subroutine  CONVRT. 

2)  Written  to  table  in  subroutine  ENTTUP . 

LEN  (LENGTH) 

description:  Integer  variable  containing  the  number  of 
characters  in  an  attribute. 

utilization : 

1)  Initialize  and  incremented  in  subroutine  FNDATT. 

2)  Determines  the  number  of  required  concatenation 
in  subroutine  CONCAN. 

LMSN  (LOSER  MISSION) 

description:  Integer  variable  containing  the  value  of 
an  actual  table  attribute. 

utilization:  (COMMON  /BLK2 / ) 

1)  Assigned  value  in  subroutine  CONVRT. 

2)  Written  to  table  in  subroutine  ENTTUP. 

MSN  (MISSION) 

description:  Integer  variable  containing  the  value  of 
an  actual  table  attribute. 

utilization:  (COMMON  /BLK2/) 

1)  Assigned  value  in  subroutine  CONVRT. 

2)  Written  to  table  in  subroutine  ENTTUP. 

NOMO 

description:  Logical  variable. 

utilization:  Global  variable  shared  between  the  Pull 
and  Pack  programs. 

1)  Set  to  true  in  program  Pull  when  an  EOF  has  been 
read  from  GAME . DAT . 

2)  Used  to  determine  last  iteration  of  REPEAT  UNTIL 
loop  in  PACK  program. 

NUMWPN  (NUMBER  OF  WEAPONS) 

description:  Integer  variable  containing  the  value  of 
an  actual  table  attribute. 

utilization:  (COMMON  /BLK2 / ) 

1)  Assigned  value  in  subroutine  CONVRT. 

2)  Written  to  table  in  subroutine  ENTTUP. 
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POS  (POSITION) 

description:  Integer  variable  containing  the  value  of 
an  index  in  character  array  ROD.  POS  is  the  first 
position  of  an  attribute. 

utilization : 

1)  Assigned  value  in  subroutine  FNDATT . 

2)  Determines  the  position  to  start  concatenations 
in  subroutine  CONCAN. 

QUANT  (QUANTITY) 

description:  Integer  variable  containing  the  value  of 
an  actual  table  attribute. 

utilization:  (COMMON  /BLK2/) 

1)  Assigned  value  in  subroutine  CONVRT. 

2)  Written  to  table  in  subroutine  ENTTUP . 


RCD  (RECORD) 

description:  Character  array  containing  the  data  that 
is  transmitted  from  the  PUSH  program. 

utilization:  (COMMON  /BLK1/ ) 

1)  Read  in  main  program. 

2)  Examined  to  determine  and  extract  attributes  in 
subroutine  FNDATT. 

3)  Elements  are  concatenated  to  form  attribute  in 
subroutine  CONCAN. 

REASON 

description:  Integer  variable  containing  the  value  of 
an  actual  table  attribute. 

utilization:  (COMMON  /BLK2/) 

1)  Assigned  value  in  subroutine  CONVRT. 

2)  Written  to  table  in  subroutine  ENTTUP. 

RLCK8  &  RLCK9  (READ  LOCK) 

description:  Integer  variables  containing  the  value  0 
or  1 . 

utilization:  RLCK8  and  RLCK9  are  global  variables 
shared  between  the  PULL  and  PACK  programs  to  coordinate 
reading  and  writing  between  the  two  processes. 

RLCK10  thru  RLCK13  (READ  LOCK) 

description:  Integer  variables  containing  the  value  0 
or  1 . 

utilization:  RLCK10  thru  RLCK13  are  global  variables 
shared  between  the  PACK  and  QUERY  programs  to 
coordinate  reading  and  writing  between  the  two 
processes. 
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SHTER  (SHOOTER) 

description:  Character  variable  containing  the  value  of 
an  actual  table  attribute. 

utilization:  (COMMON  /BLK4/) 

1)  Assigned  value  in  subroutine  CONVRT. 

2)  Written  to  table  in  subroutine  ENTTUP . 


SIDE 


description:  Character  variable  containing  the  value  of 
an  actual  table  attribute. 

utilization:  (COMMON  /BLK4/) 

1)  Assigned  value  in  subroutine  CONVRT. 

2)  Written  to  table  in  subroutine  ENTTUP. 


SMSN 


description:  Integer  variable  containing  the  value  of 
an  actual  table  attribute. 

utilization:  (COMMON  /BLK2/) 

1)  Assigned  value  in  subroutine  CONVRT. 

2)  Written  to  table  in  subroutine  ENTTUP. 

SP  (SPACE) 

description:  Character  constant  containing  the  value 

utilization:  Determines  the  end  of  a  data  record  in 
subroutine  FNDATT . 

TAG 

description:  Integer  variable  containing  the  value 
of  a  logical  I/O  unit  from  which  record  was  sent. 

utilization : 

1)  Determines  actual  attribute  assignments  in 
subroutine  CONVRT. 

2)  Determines  the  table  to  which  a  data  record  (tuple) 
is  entered  m  subroutine  ENTTUP. 

TIME 

description:  Real  variable  containing  the  value  of  an 
actual  table  attribute. 

utilization:  (COMMON  /BLK3/ ) 

1)  Assigned  value  in  subroutine  CONVRT. 

2)  Written  to  table  in  subroutine  ENTTUP. 

UNIT 

description:  Character  variable  containing  the  value  of 
an  actual  table  attribute. 
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utilization:  (COMMON  /BLK4/) 

1)  Assigned  value  in  subroutine  CONVRT. 

2)  Written  to  table  in  subroutine  ENTTUP . 

WLCK8  &  WLCK9  (WRITE  LOCK) 

description:  Integer  variables  containing  the  value  0 
or  1 . 

utilization:  RLCK8  and  RLCK9  are  global  variables 
shared  between  the  PULL  and  PACK  programs  to  coordinate 
reading  and  writing  between  the  two  processes. 

WLCK10  thru  WLCK13  (WRITE  LOCK) 

description:  Integer  variables  containing  the  value  0 
or  1 . 

utilization:  WLCK10  thru  WLCK13  are  global  variables 
shared  between  the  PACK  and  QUERY  programs  to 
coordinate  reading  and  writing  between  the  two 
processes. 

WPNTYP  (WEAPON  TYPE) 

description:  Integer  variable  containing  the  value  of 
an  actual  table  attribute. 

utilization:  (COMMON  /BLK2/) 

1)  Assigned  value  in  subroutine  CONVRT. 

2)  Written  to  table  in  subroutine  ENTTUP. 
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APPENDIX  F 
PROGRAM  PULL  CODE 

PROGRAM  PULL 

INTEGER  RLCK8, RLCK9, WLCK8 , WLCK9 
CHARACTER  INFO* 80 
LOGICAL  NOMO 

DATA  NOMO, WLCK8.WLCK9/ .FALSE .1,0/ 

OPEN  (UNIT-7. FILE-' GAME. DAT' , STATUS-' OLD' ) 

10  IF (RLCK8 .EQ. 0) THEN 
WLCKS5*! 

OPEN  (UNIT-8,  FILE-' GAME 1 . DAT ' , STATUS-' NEW' ) 

READ  (7, 100, END-20)  INFO 

WRITE (8. 100) INFO 

CLOSE  UNIT-8 

WLCK8-0 

ELSE 

WLCK9c=l 

OPEN  (UNIT-9,  FILE-' GAME 2 . DAT' , STATUS-' NEW' ) 

READ  7, 100, END-20) INFO 

WRITE (9. 100) INFO 

CLOSE  UNIT-9 

WLCK9-0 

END  IF 
GOTO  10 

20  NOMO-. TRUE. 

END 
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APPENDIX  G 

PROGRAM  PULL  CODE  DESCRIPTION 


PROGRAM  PULL 


c  This  Program  reads  data  from  the  PUSH  program  on  the  VAX 
c  and  writes  data  to  either  GAME lor  GAME 2 .  when  the  PACK 
c  program  is  reading  data  from  GAME1  data  is  written  to  GAME2 
c  and  when  the  PACK  program  is  reading  from  GAME2  data  is 
c  written  to  GAME1 .  This  allows  data  to  continually  be 
c  received  from  the  war  game  while  the  Sun  processes  data, 
c  and  players  query  the  database.  Variables  RLCK8 ,  RLCK9, 
c  WLCK9,  and  WLCK9  are  global  variables  that  allow  the  two 
c  processes  to  coordinate  reading  and  writing, 
c 

INTEGER  RLCK8 , RLCK9 , WLCK8 , WLCK9 
CHARACTER  INFO* 80 
LOGICAL  NOMO 

DATA  NOMO. WLCK8 , WLCK9/ . TRUE .,1,0/ 

OPEN  (UNIT* 7 , FILE*' GAME . DAT' , STATUS*' OLD' ) 

If  the  Pack  program  is  not  reading  from  GAME1.DAT  read  data 
from  the  PUSH  program  and  write  data  on  GAME 1 . DAT . 

10  IF (RLCK8 . EQ . 0 ) THEN 

Disable  pack  program  from  reading  GAME1.DAT. 

WLCK8*=1 

OPEN  (UNIT—8.FILE*' GAME1 . DAT' , STATUS*' NEW' ) 

READ  7, 100, END=20)  INFO 
WRITE (8. 100 [INFO 
CLOSE  UNIT-8 

Enable  Pack  program  to  access  GAME1.DAT. 


ELSE 


WLCK8-0 


If  the  Pack  program  is  reading  GAME1.DAT  disable  read  from 
GAME2.DAT,  read  record  and  write  data  on  GAME2.DAT. 

WLCK  9®1 

OPEN  (UNIT-9.FILE*' GAME 2 . DAT' , STATUS*' NEW' ) 


OPEN  (UNIT-9, FILE*' GAME; 
READ  (7, 100, END-20) INFO 
WRITE (9. 100 5  INFO 
CLOSE  UNIT-9 


WLCK9—0 

END  IF 
GOTO  10 

When  an  end  of  file  is  read  from  the  Push  Program  set 
global  variable  NOMO  to  false.  This  informs  the  Pack 
program  the  game  has  terminated. 

20  NOMO-. TRUE. 

END 
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APPENDIX  H 
PROGRAM  PACK  CODE 


10 


20 


PROGRAM  PACK 

INTEGER  INTRVL, LMSN, MSN, NUMWPN. QUANT, REASON, SMSN, TAG, 
INTEGER  WPNTYP  RCLK8, RLCK9, RLCK10, RLCK11 , RCLCK12, 

INTEGER  RLCK13,  WLCK8 , WLCK9, WLCK10, WLCKli , WLCK12 , WLCK13 
REAL  TIME 

CHARACTER* 1  RCD (80) 

CHARACTER  CONFLT*20, SHTER*10, SIDE*4 , UNIT*10 
LOGICAL  NOMO 
COMMON  /BLK1/RCD 

COMMON  / BLK2 / INTRVL , LMSN , MSN , NUMWPN , QUANT , REASON , SMSN , 
STAG, WPNTYP 
COMMON  /BLK3/TIME 

COMMON  /BLK4/CONFLT, SHTER, SIDE, UNIT 

COMMON  /BLK5 /RLCK1 0 , RLCK1 1 , RLCK1 2 , RLCK1 3 , WLCK10 , WLCK1 1 , 
SWjjCKI  2 ,  WLCK1 3 

DATA  RLCK8 , RLCK9, WLCK1 0 , WLCK1 1 , WLCK1 2 , WLCK1 3 

IF (WLCK8 . EC . 0 ) THEN 
RLCK8=1 

OPEN (UNIT-8,  FILE-' GAME1 . DAT' , STATUS-' OLD ' ) 

READ  78, 100, END-30) (RCD ( I ) 1=1 , 80 ) 

CALL  ENTTUP 
GOTO  20 

ELSE 

GOTO  10 

END  IF 

CLOSE  UNIT-8 
RLCK8-0 
IF (WLCK9 . E0 . 0 ) 

RLCK9-1 

OPEN (UNIT-9,  FILE-' GAME2 .DAT' . STATUS-' OLD) 

CALL  In6at?,END=60)  (RCD  (I)  I=r*  ,  8°) 

CALL  ENTTUP 
GOTO  50 

ELSE 

GOTO  40 
ENDIF 

CLOSE  UNIT-9 
RLCK9-0 
UNTIL  NOMO 

OPEN (UNIT-8 , FILE-' GAME1 . DAT' . STATUS-' OLD ' ) 

READ  (8, 100, END-80) (RCD (I) 1=1 , 80) 

CALL  FNDATT 
CALL  ENTTUP 
GOTO  70 
CLOSE  UNIT-8 
100  FORMAT (80A1) 

STOP 

END 


30 

40 


50 


60 


70 


80 


SUBROUTINE  FNDATT 

INTEGER  ANUM, LEN, POS, INX 
CHARACTER* 1  DELIM, RCD (80) , SP 
CHARACTER  ATTR*20 
COMMON/BLK1 /RCD 

DATA  ANUM, DELIM, INX,  LEN,  POS,  SP/1,  '&'  ,1,  0,  1,  '  '/ 
IF (RCD (INX) .EO. DELIM. OR. RCD (INX) .EQ.SP) THEN 
IF (RCD (INX) .EQ.SP) RETURN 
CALL  CONCAN  (POS, ATTR, LEN) 

CALL  CONVRT  (ANUM, ATTR, LEN) 

ANUM— ANUM+ 1 
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LEN=0 

INX=INX+1 

POS=INX 
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ELSE 

LEN=LEN+1 

INX=INX+1 

IF ( INX . GT . 80 ) PRINT* , ' RECORD  EXCEEDS  80  CHARACTERS' 

ENDIF 
GOTO  10 
END 

********************************************************** 
SUBROUTINE  CONCAN  (I,ATTR,LEN) 

INTEGER  I , LEN 
CHARACTER* 1  RCD (80) 

CHARACTER  ATTR*20 
COMMON  /BLK1/  RCD 


ATTR=' O' 
ATTR=RCD 
ATTR=RCD 
ATTR=RCD 
ATTR=RCD 
ATTR=RCD 


LEN.EQ.  0; 

LEN .  EQ .  1 
LEN . EQ . 2 
LEN.EQ. 3 
LEN . EQ . 4 
LEN  EQ . 5 
1  +  4) 

EQ . 6 ) ATTR=RCD ( I )  /  / RCD ( I  + 1 ) //RCD (1+2) //RCD (1+3) 

\  /  /or’n  / 


//RCD 

//RCD 

//RCD 


//RCD (I  +  l 


//RCD 

//RCD 

//RCD 


1  +  2 
1+2 
1+2 


//RCD (1+3) 
//RCD (1+3) 


.  RCD (1+2) 
1  +  7) 


I  ATTR=RCD (I) //RCD (1  +  1 ) //RCD ( 1  +  2 ) //RCD ( 1  +  3) 

nn  /  t  C  \  /  /  /  t  i  v  /  /  Airs  /  t  i  -»  v 


10)i 

//RCD (_ . _ . 

//RCD (1+9) 

' '  ATTR=RCD (I) //RCD ( I+l )//RCD ( 1+2 ) //RCD ( 1+3 ) 
//RCD (1+6) //RCD (I ‘ 


[  1+5  f  /  j  RCD '( 1  +  6 )  /  /R6b '( 1  +  7 ) 


/RCD (1+5) 
&//RCD (1  +  9) 
IF (LEN.EQ 
&//RCD (1+4 
& / /RCD (1+9 
(LEN 


(1  +  3) 


4//RCD  I+. 

4//RCD  1+3 
&//RCD  (l  +  8) 

IF (LEN.EQ. 

&//RCD (1+4) 

& / /RCD  (1  +  8)  //nv 

IF  ( LEN  •  EQ  •  11)^4,  ■*. i*  /  /  /  i  j,  •  jl  /  /  /  awu  i  x  i  <,  /  /  /  iwu  v  x  •  o  / 

&//RCD (I+?) 77rcd (1+5) /7r6d (1+6^ //r6d (1+7) 

&//RCD  (1  +  8) //RCD (l  +  9) //RCD  #1  +  10) 

IF ( LEN . EQ . 1 2 ) ATT R=RCD (I ) //RCD (1+1)// RCD (1+2)// RCD (1+3) 
&//RCD (1+4) //RCD (1+5) //RCD (1+6) //RCD (1+7) //RCD (1+8) 
&//RCD (1+9) //RCD (1+10) //RCD (I+ll) 

“ F ( LEN . EQ. 13) ATTR=RCD (I ) // RCD ( I + 1 ) / / RCD (1+2 ) / / RCD ( 1+3 ) 
■"  *  //RCD ( 1  +  5 )  / /RCD ( 1+6) 7 /RCD ( 1+7 ) //RCD ( 1+8 ) 
//RCD (i+lO) //RCD (I+ll) //RCD (1+12) 

14)ATTr=RCD (I) //RCD (1+1) //RCD (1+2) //RCD ( 
//RCD (1+5) //RCD (1+6) //RCD (1+7) //RCD (1+8) 

.  //RCD jl  +  10) //RCD (I  +  ll) //RCD (1  +  12) //RCD (1  +  13) 
&^F^LEN_^EJ.l,5^ATTR=RCD(I).//RCD.(3;+l^//RCD.(];  +  2^//RCp  (1  +  3) 

&//RCD  jl  +  9! //RCD il  +  1 
&//RCD (1+14) 

IF (LEN.EQ. 16)ATTR=RCD (I) //RCD (I+l) //RCD (1+2) //RCD (1+3) 
&  7 / RCD (1  +  4) //RCD (I  +  5)7/RCD  (1  +  6) 7/RCD (1  +  7) 7/RCD (1  +  8) 
&//RCD (1+9) //RCD (1+10) //RCD (I+ll) //RCD (1+12) //RCD (1+13) 
//RCD (1+15) 

7) ATTR=RCD (I) //RCD (1+1) //RCD (1+2) //RCD (1+3) 

/RCD(I+5)/7RCD(I+6) 7/RCD (1+7) 7/rcd ( - 

/RCD  1+10  ‘ 

//RCD (1+1 

18)  AT — 

7/RCD 

//RCD  __L, _ _ _  . 

) //RCD (I+l5) //RCD (1+16) 

19)  ATTR=RCD (I ) //RCD ( I  +  l ,,  _ _ _ 

7/RCD (1  +  5) //RCD (1  +  6) 7/RCD (1  +  7) 7/RCD  (1  +  8, 
//RCD  1+10) //RCD (I+ll) //RCD (1+12) //RCD (1+13) 
) //RCD (1+15) //RCD (1+16) //RCD (1+] 7) //RCD (1+18 

20)  ATTR=RCD  (I )  / /RCD  ( 1  +  1 )  //RCD  ( 1+2  W/RCD  ( 1  +  3 ) 

7/RCD (1+5) //RCD (1+6) 7/RCD (1+7) 7/rcd  - 

//RCD (I+l  '  - 


LO) //RCD (I+ll) /7RCD (1+12) //RCD (1+13) 
ICD (I) //RCD (I  +  l) //RCD (1+2) //RCD (1+3) 
5f//RCU (1+6) 7/RCD (1+7) 7/RCD (1+8) 

L0) //RCD (I+ll) //RCD (1+12) //RCD (1+13) 


&//RCD (1+14 
IF (LEN . E 
& 7/RCD (1+ 
4//RCD  1+., 
&//RCD (1+14 
IF (LEN.EQ. 
&//RCD (1+4) 
4//RCD  1+9) 
&//RCD (1+14 
IF (LEN.EQ. 
&7/RCD (1+4) 
4//RCD  1+9 
&/ /RCD (1+14 
IF (LEN.EQ. 
&7/RCD (1+4) 
4//RCD  1+9) 


3CD (I) //RCD (I+l) //RCD (1+2) //RCD (1+3) 
5)77rCD  (1  +  6) 7/RCD (1+7) 7/RCD (1+8) 

tu(^R?i5uliL)'/RCD(I+12l//RCD(  +X31 

d]i+i 


Mi  /  /  \  •  S  /  f  /  I  A  • 

&//RCD (1+14) //RCD (I 


1  J.  I  /  /  £\\^U  1T1/  l  /  XVV.,4-/  l  A.-T4.  I  /  /  £ \  J/ 

5r//RCD (1+6) 7/RCD (1+7) 7/RCD (1+8) 

10) //RCD (I  +  ll) //RCD (1  +  12) //RCD (1  +  13) 
+15) //RCD (I+l 6RCD (1+17) 
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&//RCD (1+18) //RCD (1+19) 

IF (LEN . GT .20) PRINT* , 'ATTRIBUTE  LENGTH  GREATER  THAN  20' 

RETURN 

END 

★  *****★*★★*  ****★***★*******************★★★*************★★***  — 
SUBROUTINE  CONVRT  (ANUM, ATTR, LEN ) 

INTEGER  ANUM, INTRVL, LEN, LMSN, MSN, NUMWPN, QUANT, REASON, 

& SMSN, TAG, WPNTYP 
REAL  TIME 

CHARACTER  ATTR*20,  CONFLT*20,  SHTER*10,  SIDEM,  UNIT*10 
COMMON  /BLK2/ INTRVL, LMSN, MSN, NUMWPN, QUANT, REASON, SMSN, 
&TAG, WPNTYP 
COMMON  /BLK3/TIME 

COMMON  /BLK4/CONFLT, SHTER. SIDE, UNIT 
IF (ANUM . EQ . 1 ) DECODE (LEN, 1 0  0, ATTR) TAG 
IF  ANUM. EQ . 2  DECODE  LEN, 101 , ATTR  INTRVL 
IF (ANUM. EQ. 3  DECODE (LEN, 102 , ATTR) TIME 
IF (ANUM.EQ.4) SIDE=ATTR 

IF (ANUM.EQ. 5. AND. (TAG . EQ . 10 . OR . TAG . EQ . 1 6) ) 

& DECODE (LEN, 101 , ATTR) QUANT 
IF (ANUM.EQ. 5 .AND . TAG . EQ . 12) CONFLT=ATTR 
IF (ANUM.EQ. 5 .AND . TAG . EQ . 14 j  DECODE (LEN, 1 00, ATTR) MSN 
IF (ANUM.EQ. 6) DECODE (LEN, 1 01 , ATTR) QUANT 
IF (ANUM.EQ. 7  DECODE (LEN, 100, ATTR) LMSN 
IF (ANUM . EQ . 8  SHTER=ATTR 
IF (ANUM.EQ. 9  DECODE (LEN, 100, ATTR) SMSN 
IF  ANUM.EQ. IOTdECODETlEN, 103, ATTR) WPNTYP 


IF (ANUM.EQ. 11  DECODE (LEN, 101, ATTR  NUMWPN 
I F (ANUM . EQ . 1 2  DE CODE ( LEN . 1 0  4 , ATTR ) REASON 
IF (ANUM. GT. 13) PRINT*,  'NUMBER  OF  ATTRIBUTES  EXCEEDS  12' 

100  FORMAT (12) 

101  FORMAT (15) 

102  FORMAT (FI 0. 6) 

103  FORMAT (14) 

104  FORMAT (13) 

RETURN 

END 

SUBROUTINE  ENTTUP 

INTEGER  INTRVL. LEN, LMSN, MSN, NUMWPN, QUANT, REASON , SMSN , 
STAG, WPNTYP  RLCK1 0 , RLCK1 I , RLCK1 2 , RLCK1 3 , WLCK1 0 , WLCK1 1 , 
&WLCK12.WLCK13 

real  time 

CHARACTER  CONFLT*20, SHTER*10, SIDE*4, UNIT*10 
COMMON  / BLK 2/1 NTRVL , LMSN, MSN, NUMWPN, QUANT, REASON, SMSN, 
STAG, WPNTYP 
COMMON  /BLK3/TIME 

COMMON  /BLK4/CONFLT, SHTER, SIDE, UNIT 

COMMON  /BLK5/RLCK1 0 , RLCK1 1 , RLCK1 2 , RLCK1 3 , WLCK1 0, WLCK1 1 , 
& WLCK1 2 , WLCK1 3 
I F ( TAG . EQ . 1 0 ) THEN 
10  IF (RLCK10 . EQ . 0) THEN 

WLCK10*1 

OPEN (UNIT-10, FILE=' ACAVAIL. SQL' , STATUS=' OLD' ) 
WRITE (10, 1 00  5 INTRVL, TIME, SIDE, UNIT, QUANT 
CLOSE  UNIT=10 
WLCK1G=0 

ELSE 

GOTO  10 

END  IF 

ENDIF 

IF (TAG. EQ. 11) THEN 
20  IF (RLCK11 ,EQ. 0) THEN 

WLCK1 1=1 

OPEN (UNIT-11, FILE=' ACKILLED . SQL' , STATUS=' OLD' ) 
WRITE (11, 101  INTRVL, TIME, SIDE,  UNIT, CONFLT, 


vr  uiui*  Jr  x  f  c  j.  j.  udcju  •  oyu  #  uirnuu- 

WRITE (11, 101) INTRVL, TIME. SIDE. UNIT, CONFLT, 
QUANT, LMSN, SHTER, SMSN, WPNTYP, NUMWPN, REASON 


ELSE 


CLOSE  UNIT=*11 
WLCK1 1=0 


GOTO  20 

ENDIF 
END  IF 

IF (TAG. EQ. 12) THEN 

IF (RLCK12 .EQ. 0) THEN 
WLCK12=1 


OPEN  (UNIT=12,FILE='ACLAUNCH.  SQL'  .STATUS" '  OLD'  ) 
WRITE (12, 1025 INTRVL, TIME, SIDE, UNIT, MSN, QUANT 
CLOSE  UNIT=12 

T*TT  PV1  O  —  n 


ELSE 

ENDIF 

ENDIF 
IF (TAG . EQ . 
IF  (RL 


WLCK12=0 
GOTO  30 


.13) THEN 
.LCKl  3  .  EQ .  0 )  THEN 
WLCK13=1 

OPEN (UNIT=13, FILE=' ACREM. SQL' , STATUS=' 
WRITE (13, 100  INTRVL, TIME, SIDE, UNIT, QUP 


ELSE 


WRITE (13. 1005 INTRVL, TIME, SIDE, UNIT, QUANT 

CLOSE  UNIT=13 

WLCK13=0 


OLD'  ) 


GOTO  40 

ENDIF 

ENDIF 

100  FORMAT ( I 5 , F 1 0 . 6 , A4 , A1 0 , 15) 

101  FORMAT (15, F10. 6, A4, A10, A20, 15, 12, A10, 12,15,13) 

102  FORMAT ( I 5 , F 1 0 . 6 , A4 ,A10, 12, 1 5 ) 

RETURN 

END 
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APPENDIX  I 

PROGRAM  PACK  CODE  DESCRIPTION 


PROGRAM  PACK 


c  The  PACK  program  will  read  data  from  whichever  file, 
c  GAME1.DAT  or  GAME2.DAT,  that  is  not  being  written  to  by 
c  the  PULL  program.  Once  a  file  has  been  opened  the  PULL 
c  program  is  prevented  from  writing  to  the  open  file  until 
c  all  records  have  been  read,  deciphered,  and  c  placed  into 
-  the  proper  JTLS  table.  When  an  end  of  file  has  beer  read 
the  rile  will  be  closed  and  made  accessible  to  the  PULL 
program.  The  process  continues  alternating  between  files 
until  the  global  variable  is  set  to  true  by  the  Pull 
program. 


&WPNTYP , 

&WLCK9 
REAL  TIME 
CHARACTER* 1  RCD(80) 

CHARACTER  CONFLT*20, SHTER*10, SIDE*4, UNIT*10 
LOGICAL  NOMO 
COMMON  /BLK1/RCD 

COMMON  /BLK2/INTRVL, LMSN, MSN, NUMWPN, QUANT, REASON, SMSN, 
STAG, WPNTYP 
COMMON  /BLK3/TIME 

COMMON  /BLK4/CONFLT, SHTER, SIDE, UNIT 

COMMON  /BLK5/RCLK1 0 , RCLKl 1 , RCLK1 2 , RLCK13 , WLCK1 0 , WLCK1 1 , 
&WLCK1 2 . WLCK1 3 

DATA  RLCK8 , RLCK9 , WLCK1 0 , WLCK1 1 , WLCK1 2 , WLCK1 3 
S/0, 0,0, 0,0,  0/ 

Alternate  reading  files  until  global  variable  NOMO  is  true. 
REPEAT 

If  Pull  program  is  not  writting  to  GAME 1 . DAT  disable 
access,  read,  and  process  data. 


10 


20 


IF ( WLCK8 . EQ . 0 ) THEN 
RLCK8=1 

OPEN (UNIT=8,FILE='GAME1 .DAT, ' STATUS='OLD' ) 
READ (8, 100, END=30) (RCD ( I ) 1=1 , 80 ) 


Process  record  by  finding  attributes  and  placing  into 
appropriate  tables. 

CALL  FNDATT 
CALL  ENTTUP 

Read  file  until  end. 

GOTO  20 

ELSE 

Attempt  access  until  permitted. 

GOTO  10 

END  IF 

Close  file  and  enable  access  to  Pull  program,  when  an  end 
of  file  is  read  from  GAME1.DAT. 


30 


CLOSE  UNIT=8 
RLCK8-0 


c 
c 

c  access 


If  Pull  program  is  not  writting  to  GAME2.DAT  disable 


l  progr 
,  read. 


% 


and  process  data. 
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C 

40  IF (WLCK9 . EQ . 0 ) THEN 

RLCK9=1 

OPEN  (UNIT=9,FILE=' GAME2 .DAT' , ' STATUS®' OLD' ) 

50  READ (9, 100,END=30)  (ROD  (I) 1=1, 80) 

c 

c  Process  record  by  finding  attributes  and  placing  into 
c  appropriate  tables . 

CALL  FNDATT 
CALL  ENTTUP 
c 

c  Read  file  until  end. 

GOTO  50 

ELSE 

c 

c  Attempt  access  until  permitted. 

GOTO  40 

ENDIF 

60  CLOSE  UNIT=9 

RLCK9=0 
c 

c  Process  is  repeated  until  NOMO  is  set  to  true, 
c 

UNTIL  NOMO 

C 

c  While  reading  GAME2.DAT  during  the  last  iteration,  the  Pull 
c  program  could  be  placing  the  final  set  of  data  into 
c  GAME1.DAT  and  set  NOMO  to  true.  This  block,  of  instruction 
c  outside  the  REPEAT  UNTIL  loop  will  ensure  that  GAME 1 . DAT 
c  will  be  read, 
c 

OPEN (UNIT=8, FILE=' GAME1 . DAT, ' STATUS= 'OLD' ) 

70  READ (8, 100,END=80) (RCD (I) 1=1, 80) 
c 

c  Process  record  by  finding  attributes  and  placing  into 
c  appropriate  tables . 

CALL  FNDATT 
CALL  ENTTUP 

c 

c  Read  file  until  end. 

GOTO  70 

80  CLOSE  UNIT=8 
STOP 

100  FORMAT  ( 80A1 ) 

END 

★  ★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★ 
SUBROUTINE  FNDATT 

C 

c  This  subroutine  determines  the  length  and  starting 
c  positions  of  attributes.  When  the  end  of  an  attribute 
c  (DEL)  has  been  located  subroutine  CONCAN  is  called  to 
c  concatenate  the  characters  contained  in  the  attribute, 
c  Subroutine  CONVRT  is  called  to  DECODE  and  assign  value  to 
c  the  actgal  table  attributes .  When  a  space  has  been  located 
c  the  rotine  will  terminate. 

°  INTEGER  ANUM.LEN.POS, INX 

CHARACTER* 1  DELIM, RCD ( 80) , SP 
CHARACTER  ATTR*  20 
COMMON/BLK1 /RCD 
c 

c  Initialize  variables 
c 

DATA  ANUM, DELIM, INX,LEN,POS, SP/1, ' &' , 1, 0, 1, '  ' / 

c 
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The  search  for  attributes  continues  until  the  last 
character  is  located. 


10  IF 


(RCD  (INX). EQ . DELIM . OR . RCD (INX) .EQ.SP) THEN 
IF (RCD ( INX) .EQ.SP) RETURN 


;  Concatenate  characters  of  attribute. 

CALL  CONCAN  (POS, ATTR, LEN) 

:  Convert  and/or  assign  actual  attribute. 

CALL  CONVRT  (ANUM, ATTR, LEN) 

* 

:  Increment  attribute  number  and  array  index,  initialize 
:  attribute  length  and  assign  the  next  attribute's  starting 
:  position. 

ANUM-ANUM+ 1 
LEN-0 
INX-INX+1 
POS=INX 

ELSE 

Increment  attribute  length  and  array  index  if  the  end  of  an 
attribute  or  a  record  is  not  found.  A  error  message  will 
be  printed  if  the  record  exceeds  80  characters. 

LEN-LEN+1 

INX—INX+1 

IF (INX. GT. 80) PRINT*, 'RECORD  EXCEEDS  80  CHARACTERS' 

END  IF 
GOTO  10 
END 

SUBROUTINE  CONCAN  (I, ATTR, LEN) 

This  subroutine  concatenates  the  characters  elements  of 
the  attribute  into  a  single  character  variable.  The  number 
of  required  concatenations  is  determined  by  the  length  of 
the  attribute  (LEN) . 

INTEGER  I , LEN 
CHARACTER* 1  RCD (80) 

CHARACTER  ATTR* 20 
COMMON  /BLK1/  RCD 

:  We  were  unable  to  confirm  if  all  attributes  were  mandatory. 
:  We  included  a  case  for  length  zero  for  this  possiblity. 


IF (LEN.EQ. 
IF  (LEN.EQ. 
IF l LEN.EQ. 
IF (LEN.EQ. 
IF  LEN.EQ. 
IF (LEN.EQ. 
&//RCD (1+4 ) 
IF (LEN.EQ. 
& / /PCD (1+4 ) 
IF (LEN.EQ. 
&/ /RCD (1+4) 
IF (LEN.EQ. 
& / /RCD (1  +  4 ) 
IF (LEN.EQ. 
&//RCD (1+4) 
IF  (LEN . EQ . 
& //RCD (1+4) 
& / /RCD  (1  +  9) 
IFJLEN.EQ. 
&//RCD (1+4) 
4//RCD (l+9) 


0 ) ATTR- 'O' 

1 )  ATTR-RCD  I ) 

2)  ATTR-RCD  I) //RCD (I  +  l) 

3  ATTR-RCD  I  //RCD  I  +  l  //RCD (1+2) 

4  )  ATTR-RCD  (i  //RCD  (i  +  l  j  //RCD  (1  +  2  //RCD  (1  +  3) 
5) ATTR-RCD (I) //RCD (I+l ) //RCD (1+2) //RCD (1+3) 


6)  ATTR-RCD 
//RCD (1+5) 

7)  ATTR-RCD 
//RCD (1+5) 

8)  ATTR-RCD 
//RCD (1+5) 

9)  ATTR-RCD 


(I)  //RCD (I  +  l) //RCD (1  +  2) //RCD  (1  +  3) 

^^//RCD^  +  D/ZRCDd  +  P)  //RCD  (1  +  3) 

(I)  //RCD  (1  +  1)  //RCD  (1  +  2)  //RCD  (1  +  3) 
//RCD (1+6) //RCD (1+7^ 

[1)7/  RCD  (1  +  1)7/  RCD  - 


//RCD (1+5) 
10 ) ATTR-RC 
//RCD(I+5) 


//RCD (1+6) //RCD (1+7) //RCD (1+8) 
D (I) //RCD (I  +  l) //RCD (1  +  2) //RCD  < 
//RCD (1+6) //RCD (1+7) //RCD (1+8) 


CD  (1  +  3) 

1  +  8) 

RCD (1+3) 


11) ATTR-RCD (I) //RCD (I+l) / 
//RCD ( 1+5 ) / /RCD (1+6) / /RCD 
//RCD  1+10) 


//RCD  (I 
D  ( 1  +  7 )  / 


+2) //RCD (1+3) 
/RCD (1+8) 


■;wi rv»  i ru  w-- 


IF (LEN . EQ . 12) ATTR=RCD (I) / /RCD (1  +  1) / /RCD (1+2 ) / /RCD (1+3 ) 
&//RCD (1+4) //RCD (1  +  5)7 /RCD (1  +  6) //RCD (1  +  7) //RCD (1  +  8) 
&//RCD (1+9) //RCD jl+10) //RCD (I+ll) 

IF (LEN . EQ . 13) ATtR=RCD (I ) //RCD ( 1  +  1 ) / /RCD ( 1  +  2 ) //RCD  < 1  +  3 ) 
&//RCD (1+4) //RCD (I+5)7/RCD (1+6) //RCD (1+7 ) //RCD ( 1+8) 
&//RCD (1  +  9) //RCD (I+l6)//RCD (I+ll) //RCD (1+12) 

IF (LEN.EQ. 14) ATTR=RCD (I ) //RCD ( 1+1 ) //RCD (1+2) //RCD (1+3) 
&//RCD (1+4) //RCD (I+5T//RCD (1+6) //RCD (1+7) //RCD (1+8) 
&//RCD (1  +  9) //RCDjl+10) //RCD ( 1+1 1 ) //RCD ( 1+12 ) //RCD (1+13) 
IF (LEN.EQ. 15) ATTR=RCD (I) //RCD ( 1+1 ) / /RCD ( 1+2 ) //RCD ( 1+3 
&//RCD (1+4) //RCD (I+5r7/RCD (1+6) //RCD (1+7) //RCD (1+8) 
&//RCD  1+9) //RCD (1+10) //RCD (I+ll) //RCD (1+12) //RCD (1+13) 


&//RCD 
&//RCD 
&//RCD  ( 

IF (LEN 
&//RCD ( 

&//RCD 
&//RCD ( 

IF (LEN 

&/^rcd  |i+9)  /'/rcd  (i+16')  Z/rci3  u+H)77r£d  '(i+i^)77Acd'(1+13) 
&//RCD (1+14 ) //RCD (1+15) //RCD?I+16 
IF ( LEN . EQ . 1 8 ) ATTR=RCD ( I ) / / RCD (1+1) //RCD (1+2) //RCD (1+3) 
&//RCD (1+4) //RCD (1+5) //RCD (1+6) //RCD (1+7) //RCD (1+8) 

&//RCD  1+9) //RCD (1+10) //RCD (I+ll) //RCD (1+12) //RCD (1+13) 
&//RCD (1+14) //RCD (1+15) //RCD (1+16) //RCD (1+17) 

IF (LEN.EQ. 19) ATTR=RCD (I ) //RCD ( 1+1 ) //RCD ( 1+2 ) //RCD (1+3) 
&//RCD (1+4) //RCD (1+5) //RCD (1+6) //RCD (1+7) //RCD (1+8) 
&//RCD(I+9) 

&//RCD (1+10) //RCD (I+ll) //RCD (1+12) //RCD (1+13) 

&//RCD(l+14) //RCD (1+15) //RCD (1+16) //RCD  1+17  //RCD (1+18) 
IF (LEN.EQ.20)ATTR=RCD(I) //RCD(I+1) //RCD (1+2) //RCD  1+3) 
&//RCD (1+4) //RCD (I+57//RCD (1+6) //RCD (1+7) //RCD (1+8) 

S//RCD  1+9) //RCD  1+10) //RCD (I+ll) //RCD (1+12) //RCD (1+13) 

& //RCD  1+14) //RCD (1+15) //RCD (1+16) //RCD (1+17) //RCD (1+18) 
&/ /RCD (1+19) 

IF (LEN.GT. 20) PRINT*, 'ATTRIBUTE  LENGTH  GREATER  THAN  20' 

RETURN 

END 

************************************************************ 
SUBROUTINE  CONVRT  (ANUM, ATTR, LEN) 
c 

c  This  subroutine  determines  the  table  and  tables  actual 
c  attributes.  Once  the  determination  has  been  made  the 
c  character  value  is  decoded  if  required,  and  the  value  of 
c  the  actual  attribute  is  assigned, 
c 

INTEGER  ANUM, INTRVL, LEN, LMSN, MSN, NUMWPN, QUANT, REASON, 
&SMSN, TAG 
REAL  TIME 

CHARACTER  ATTR*20, CONFLT*20. SHTER*10, SIDE*4,  UNIT*10 
COMMON  /BLK2/INTRVL, LMSN, MSN, NUMWPN, QUANT , REASON , SMSN, 
STAG, WPNTYP 
COMMON  /BLK3/TIME 

COMMON  /BLK4/CONFLT, SHTER, SIDE, UNIT 
c 

c  The  table  identifier  is  always  the  first  attribute.  It  is 
c  also  used  to  determine  other  attribute  assignments. 

IF (ANUM . EQ . 1 ) DECODE ( LEN ,100, ATTR ) TAG 
c 

c  Identify  and  assign  values  to  other  attributes. 

IF ( ANUM. EQ. 2) DECODE (LEN, 101, ATTR) INTRVL 
IF (ANUM . EQ . 3  DECODE/LEN, 102 , ATTR) TIME 


1  +  4)  / 
1  +  9)  / 
1  +  14) 

.  EQ .  1 


//RCD (1+5)/ 
//RCD (1+10) 


.  EQ . i 6 )  ATTR=RCD (I) //RCD (1+1) //RCD (1  +  2) //RCD  (1  +  3) 
1+4) //RCD (I+51//RCD (1+6) //RCD (1+7) //RCD (1+81 
1+9) //RCD (1+10) //RCD (I+ll) //RCD (1+12) //RCD (1+13) 

t _i_  1  *  \  /  /orn  (Txi  t) 


,  ,  ,  )E (LEN,  . 

IF (ANUM . EQ . 3  DECODE|LEN, 102, ATTR) TIME 
IF (ANUM. EQ. 4 ) SIDE^ATTR 

IF (ANUM . EQ . 5 . AND . (TAG . EQ . 1 0 . OR . TAG . EQ . 1 6 ) ) 
&DECODE (LEN, 101. ATTR) QUANT 
I F (ANUM . EQ . 5 . AND . TAG . EQ . 1 2 ) CONFLT-ATTR 
IF  ANUM . EQ . 5 . AND . TAG . EQ . 1 4 ) DECODE (LEN,  1 00 , , 
I F (ANUM . EQ . 6 ) DECODE ( LEN ,101, ATTR) QUANT 


10 2, ATTR) TIME 


IF  ANUM. EQ. 5. AND. TAG. E 
IF (ANUM . EQ . 6 ) DECODE ( LE 


DECODE (LEN, 1 00 , ATTR) MSN 
, ATTR) QUANT 


■  A  *’ 


OOO  OOO  OOOOOOOOO  0  9)00  *  ooooo 


VFVl  VWWW  uv  lt»  «. 


IF 

IF 

IF 

IF 

IF 

IF 


ANUM . EQ . 7 ) DECODE ( LEN ,100, ATRR ) LMSN 
(ANUM . EQ . 8  SHTER-ATTR 
(ANUM . EQ . 9 ) DECODE ( LEN- 103, ATTR ) SMSN 
i  ANUM. EQ. 10) DECODE (LEN, 1 03 , ATTR) WPNTYP 
i  ANUM . EQ . 1 1 ) DECODE  LEN ,101, ATTR) NUMWPN 
(ANUM . EQ . 1 2 ) DECODE ( LEN ,104, ATTR) REASON 


The  maximun  number  of  attributes  in  any  table  is  12. 

An  error  message  is  printed  is  more  than  12  attributes 
have  been  located. 


IF (ANUM. GT . 12 ) PRINT* ,  ' NUMBER  OF  ATTRIBUTES  EXCEEDS  12' 

100  FORMAT (12) 

101  FORMAT (15) 

102  FORMAT  F10. 6) 

103  FORMAT  14) 

104  FORMAT (13) 

RETURN 

END 

************************************************************ 
SUBROUTINE  ENTTUP 

This  subroutine  determines  which  table  to  enter  the 
ttributes  into  and  then  makes  the  entry. 

INTEGER  INTRVL, LEN, LMSN. MSN, NUMWPN, QUANT, REASON, SMSN, 
STAG, WPNTYP, RLCK1 0 , RLCK1 1 , RLCK1 2 , RLCK, 1 3 , WLCKl 0 , WLCKl 1 , 

& WLCKl 2 .WLCKl 3 
REAL  TIME 

CHARACTER  CONFLT*20, SHTER*10, SIDE*4, UNIT*10 
COMMON  /BLK2 / INTRVL , LMSN , MSN , NUMWPN , QUANT , REASON , SMSN , 
STAG, WPNTYP 
COMMON  /BLK3/TIME 

COMMON  /BLK4/CONFLT, SHTER, SIDE, UNIT 

COMMON  /BLK5/RCLK1 0 , RCLKl 1 , RCLK1 2 , RLCK1 3 , WLCKl 0 , WLCKl 1 , 
& WLCKl 2 , WLCKl 3 

The  appropriate  table  is  determined  by  the  variable  TAG. 

If  the  corresponding  ORACLE  database  is  accessible  (not 
being  queried),  query  access  is  disabled  and  the  record  is 
entered  into  the  table.  The  file  is  then  closed  to  enable 
queries.  If  the  table  is  not  accessible  the  program  will 
attempt  access  until  obtained. 


IF (TAG. EQ. 10) THEN 
"TTRLCK* “  “ 


10 . EQ. 0) THEN 
WCLK10-1 


10  IF 

OPEN (UNIT— 10,  FILE-' ACAVAIL .  SQL'  ,  STATUS**'  OLD'  ) 
WRITE (10, 100) INTRVL, TIME, SIDE, UNIT, QUANT 

Allow  access  by  query  programs  after  writting  into  table. 

CLOSE  UNIT-10 
WCLK10-0 

ELSE 

GOTO  10 

END  IF 

END  IF 

IF ( TAG . EQ .11) THEN 
20  IF (RLCK11 . EQ . 0) THEN 

WLCKl 1-1 

OPEN (UNIT-11,  FILE-' ACKILLED . SQL' .STATUS-' OLD' ) 
WRITE (11, 101) INTRVL, TIME, SIDE, UNIT,  CONFLT, 

&  QUANT, LMSN, SHTER, SMSN, WPNTYP, NUMWPN, REASON 

Allow  access  by  query  programs  after  writting  into  table. 

CLOSE  UNIT-11 
WLCKl 1-0 
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30 


ELSE 

GOTO  20 

END  IF 

ENDIF 

IF (TAG.EQ. 12) THEN 

IF (RLCK12 . EQ. 0) THEN 
WLCK12=1 


OPEN  (UNIT=12 , FILE*' ACLAUNCH . SQL' .STATUS*' OLD' ) 
WRITE (12, 102) INTRVL, TIME, SIDE, UNIT, MSN, QUANT 

Allow  access  by  query  programs  after  writting  into  table. 

CLOSE  UNIT=12 
WLCK12=0 

ELSE 

GOTO  30 

ENDIF 

ENDIF 

IF (TAG.EQ. 13) THEN 
40  IF (RLCK13 .EQ. 0) THEN 

WLCK13=1 

OPEN (UNIT=13, FILE*' ACREM. SQL' , STATUS*' OLD' ) 
WRITE (13, 100[lNTRVL, TIME, SIDE, UNIT, QUANT 
CLOSE  UNIT=13 
WLCK13*0 

Allow  access  by  query  programs  after  writting  into  table. 
ELSE 

GOTO  40 

ENDIF 

ENDIF 

100  FORMAT (15, F10 . 6, A4 , A10 , 15 ) 

101  FORMAT  I5,F10. 6, A4, A10, A20, 15, 12, A10, 12, 15, 13) 

102  FORMAT ( 15 , F10 . 6,  A4 ,  A10,  12 , 15 ) 

RETURN 

END 
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APPENDIX  J 
RELATIONS 


ACAVAIL  ( INTRVL,  TIME,  SIDE,  UNIT,  QUANTITY) 

Key:  (INTRVL,  TIME,  UNIT) 

ACKILLED  (INTRVL,  TIME,  SIDE,  UNIT,  CONFLICT,  QUANTITY, 

L  MISSION,  SHOOTER,  S  MISSION,  WPN  TYPE,  NO  WPNS,  REASON) 
-  Key:  (INTRVL,  TIME,  UNIT)  ~  ~ 

ACLAUNCH  (INTRVL,  TIME,  SIDE,  UNIT,  MISSION,  QUANTITY) 
Key:  (INTRVL,  TIME,  UNIT) 

ACREM  (INTRVL,  TIME,  SIDE,  UNIT,  QUANTITY) 

Key:  (INTRVL,  TIME,  UNIT) 

CALIVE  (INTRVL,  TIME,  SIDE,  UNIT,  QUANTITY) 

Key:  (INTRVL,  TIME,  UNIT) 

CAVAIL  (INTRVL.  TIME.  SIDE,  UNIT,  QUANTITY) 

Key:  (INTRVL,  TIME,  UNIT) 

COMBATSYS  (CODE,  SIDE,  CS) 

Key:  CODE 

CSATT  (INTRVL,  TIME,  SIDE,  UNIT,  CS,  REASON,  QUANTITY) 
Key:  (INTRVL,  TIME,  UNIT,  CS) 

CSKV  (INTRVL,  TIME,  SIDE,  UNIT,  VICTIM,  KILLER,  QUANTITY) 
Key:  (INTRVL,  TIME,  UNIT,  VICTIM) 

CSLOST  (INTRVL,  TIME,  SIDE,  UNIT,  CS,  REASON,  QUANTITY) 
Key:  (INTRVL,  TIME,  UNIT,  CS) 

CSONHAND  (INTRVL,  TIME,  SIDE,  UNIT,  CS,  QUANTIY) 

Key:  (INTRVL,  TIME,  UNIT,  CS) 

CSRECD  (INTRVL,  TIME,  SIDE,  UNIT,  CS,  REASON,  QUANTITY) 
Key:  (INTRVL,  TIME,  UNIT,  CS) 

DATA  BASE  (NAME,  CLASS) 

K5y :  NAME 

DAYNIGHT  (INTRVL,  TIME,  SUNUP) 

Key:  (INTRVL,  TIME) 

DICTIONARY  (TERM,  TABLE,  MEANING) 

Key:  (TERM,  TABLE) 

DIRECTORY  (TABLE,  CONTENTS,  EVENTS) 

Key:  TABLE 

HUMINT  (INTRVL,  TIME,  SIDE,  UNIT,  QUANTITY) 

Key:  (INTRVL,  TlME,  UNIT) 

MISSIONS  (CODE,  MISSION) 

Key:  CODE 

MS LF I RED  (INTRVL,  TIME,  SIDE,  UNIT,  QUANTITY) 

Key:  (INTRVL,  TIME,  UNIT) 

NAVARRNG  j  INTRVL,  TIME,  SIDE,  UNIT,  AR  Rl.G) 

Key:  (INTRVL,  TIME,  UNIT) 

NAVMSRNG  (INTRVL,  TIME,  SIDE,  UNIT,  MS  RNG) 

Key:  (INTRVL,  TIME,  UNIT)  “ 
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NAVSPEED  ( INTRVL,  TIME,  SIDE,  UNIT,  SPEED) 

Key:  (INTRVL,  TIME,  UNIT) 

NAVSRRNG  (INTRVL,  TIME,  SIDE,  UNIT,  SR  RNG) 

Key:  (INTRVL,  TIME,  UNIT)  “ 

ORDERS  (INTRVL,  TIME  SENT,  SIDE,  ORDER  TYPE,  UNIT, 
TIME  SPEC)  ~ 

K®y :  (INTRVL,  TIME_SENT,  UNIT) 

PPSTATUS  (INTRVL,  TIME,  STATUS) 

Key:  (INTRVL,  TIME) 


REASONS  (CODE,  REASON) 

Key :  CODE 

SCDEC  (INTRVL,  TIME,  TARGET,  CATEGORY,  REASON,  QUANTITY) 

Key:  (INTRVL,  TIME,  TARGET,  CATEGORY) 

SCDUEIN  (INTRVL,  TIME,  SIDE,  UNIT,  CATEGORY,  QUANTITY) 

Key:  (INTRVL,  TIME,  UNIT,  CATEGORY) 

SCDUEOUT  (INTRVL,  TIME,  SIDE,  UNIT,  CATEGORY,  QUANTITY) 

Key:  (INTRVL,  TIME,  UNIT,  CATEGORY) 

SCINC  (INTRVL,  TIME.  TARGET,  CATEGORY,  REASON,  QUANTITY) 

Key:  (INTRVL,  TIME,  TARGET,  CATEGORY) 

SCINDUMP  (INTRVL,  TIME,  TARGET,  CATEGORY,  QUANTITY) 

Key:  ( INTRVL,  TIME,  TARGET,  CATEGORY) 

SCLOST  (INTRVL,  TIME,  SIDE,  UNIT,  CATEGORY,  REASON, 

QUANTITY,  ACTION) 

Key:  (INTRVL,  TIME,  UNIT,  CATEGORY) 

SCONHAND  (INTRVL,  TIME,  SIDE,  UNIT,  CATEGORY,  QUANTITY) 

Key:  (INTRVL,  TIME,  UNIT,  CATEGORY) 

SCRECD  (INTRVL,  TIME,  SIDE,  UNIT,  CATEGORY,  REASON, 

QUANTITY) 

Key:  (INTRVL,  TIME,  UNIT,  CATEGORY) 

SCSENT  (INTRVL,  TIME,  SIDE,  UNIT,  CATEGORY,  REASON, 

QUANTITY) 

Key:  (INTRVL,  TIME,  UNIT,  CATEGORY) 

SCSHORT  (INTRVL,  TIME,  SIDE,  UNIT,  CATEGORY,  REASON, 
QUANTITY) 

Key:  (INTRVL,  TIME,  UNIT,  CATEGORY) 

SCTRANS  (INTRVL,  TIME,  SIDE,  UNIT,  REASON,  DRY  WT,  WET  WT) 
Key:  ( INTRVL,  TIME,  UNIT)  -  ~ 

SUPPLIES  (CODE,  SIDE,  CATEGORY) 

Key:  CODE 

T ALIVE  (INTRVL,  TIME.  SIDE,  UNIT,  QUANTITY) 

Key:  (INTRVL,  TIME,  UNIT) 

TARGETS  (INTRVL,  TIME,  ID,  NAME,  CATEGORY) 

Key:  (INTRVL,  TIME,  ID) 

TAVAIL  (INTRVL,  TIME.  SIDE,  UNIT,  QUANTITY) 

Key:  (INTRVL,  TIME,  UNIT) 

TGADA  (INTRVL,  TIME,  ID,  STATUS) 
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RELATIONS 


Key: 

(INTRVL, 

TIME, 

ID) 

TGCAPABLE 

(INTRVL, 

TIME, 

ID, 

ACTION,  REASON,  PCT_CAPABLE) 

Key: 

(INTRVL, 

TIME, 

ID) 

TGDETECT 

(INTRVL, 

TIME, 

ID( 

idJ 

SIDE,  REASON) 

Key : 

(INTRVL, 

TIME, 

TGRANGE  ( INTRVL,  TIME,  ID,  RNG) 

Key:  (INTRVL,  TIME,  ID) 

TGSIDE  (INTRVL,  TIME.  ID,  SIDE) 

Key:  (INTRVL,  TIME,  ID) 

TGSIZE  (INTRVL,  TIME.  ID,  SIZE) 

Key:  (INTRVL,  TIME,  ID) 

TGUNIT (INTRVL,  TIME,  ID,  UNIT,  LAT,  LON) 

Key:  (INTRVL,  TIME,  ID) 

TRKILLED  (INTRVL,  TIME,  SIDE,  UNIT,  CARGOS,  TANKERS,  REASON) 
Key:  (INTRVL,  TIME,  UNIT) 

UNITS  (SHORT  NAME,  LONG  NAME,  TYPE,  SUBTYPE,  SIDE,  AIRCRAFT) 
Key :  SHOKT_NAME  ~ 

UTADA  (INTRVL,  TIME,  SIDE.  UNIT,  STATUS) 

Key:  (INTRVL,  TIME,  UNIT) 

UTAIRBASE  (INTRVL,  TIME,  SIDE,  UNIT,  AIRBASE)  REASONS 
Key:  (INTRVL,  TIME,  UNIT) 

UTARRIVES  (INTRVL,  TIME,  SIDE,  UNIT,  LAT,  LON) 

Key:  (INTRVL,  TIME,  UNIT) 

UTCAS  (INTRVL,  TIME,  SIDE.  UNIT,  SQUADRON,  NO  AIRCRAFT) 

Key:  (INTRVL,  TIME,  UNIT)  ~ 

UTCONTACT  (INTRVL,  TIME,  UNIT1,  UNIT2,  STATUS,  POSTURE1, 
POSTURE2 ) 

Key:  (INTRVL,  TIME,  UNITl,UNIT2) 

UTDELAYED  (INTRVL,  TIME,  SIDE,  UNIT,  DELAYER  SIDE,  LAT,  LON, 
DURATION)  ~ 

Key:  (INTRVL,  TIME,  UNIT) 

UTHQ  (INTRVL,  TIME,  SIDE.  UNIT,  HQ,  REASON) 

Key:  (INTRVL,  TIME,  UNIT) 

UTINCAR  (INTRVL,  TIME,  SIDE,  UNIT,  INC) 

Key:  (INTRVL,  TIME,  UNIT) 

UTLIFTED  (INTRVL,  TIME,  SIDE,  UNIT,  LIFTED,  STATUS,  REASON) 
Key:  (INTRVL,  TIME,  UNIT) 

UTPOSTURE  (INTRVL,  TIME,  SIDE,  UNIT,  NEW  POSTURE, 
OLD  POSTURE.  LAT,  LON)  ~ 

Key;  (INTRVL,  TIME,  UNIT) 

UTREINF  (INTRVL,  TIME,  SIDE,  UNIT,  REINFORCER,  STATUS) 

Key:  (INTRVL,  TIME,  UNIT) 

UTSTART  (INTRVL,  TIME,  SIDE,  UNIT,  LAT,  LON,  DEST  LAT, 
DEST  LON) 

K^y:  (INTRVL,  TIME,  UNIT) 
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UTSTOP  (INTRVL,  TIME,  SIDE,  UNIT,  LAT,  LON,  REASON) 
Key:  (INTRVL,  TIME,  UNIT) 

UTSTRNGTH  (INTRVL,  TIME,  SIDE,  UNIT,  STRENGTH) 

Key:  (INTRVL,  TIME,  UNIT) 

UTSUPPORT  (INTRVL,  TIME,  SIDE,  UNIT,  SUPPORT  UNIT, 
Key:  (INTRVL,  TIME,  UNIT) 

UTTRANS  (INTRVL,  TIME,  SIDE,  UNIT,  DRY  WT,  WET  WT, 
Key:  (INTRVL,  TIME,  UNIT)  ~~  “ 

WEAPONS  (CODE,  TYPE,  SIDE) 

Key :  CODE 

WPNEXPEND  (INTRVL,  TIME,  SIDE,  UNIT,  MISSION, 
TYPE,  REASON) 

Key:  (INTRVL,  TIME,  UNIT) 


REASON) 

REASON) 

QUANTITY, 


INTERRELATION  CONTRAINTS 


ACAVAIL  [UNIT] 
ACKILLED  [UNIT] 
ACKILLED  [L_MISSION] 
ACKILLED  [SHOOTER] 
ACKILLED  [S_MISSION] 
ACKILLED  [WPN_TYPE] 
ACKILLED  [NO_WPNS] 
ACKILLED  [REASON] 
ACLAUNCH  [UNIT] 
ACLAUNCH  [MISSION] 
ACREM  [UNIT] 

CALIVE  [UNIT] 

CAVAIL  [UNIT] 

CSATT  [UNIT] 

CSATT  [CS] 

CSATT  [REASON] 

CSKV  [UNIT] 

CSKV  [VICTIM] 

CSKV  [KILLER] 

CSLOST  [UNIT] 

CSLOST  [REASON] 
CSONHAND  [UNIT] 
CSONHAND  [CS] 

CSRECD  [UNIT] 

CSRECD  [CS] 

CSRECD  [REASON] 
HUMINT  [UNIT] 

MS LF I RED  [UNIT] 
NAVARRNG  [UNIT] 
NAVSPEED  [UNIT] 
NAVSRRNG  [UNIT] 
ORDERS  [UNIT] 

SCDEC  [TARGET] 


SUBSET  OF  UNIT  [SHORT_NAME] 
SUBSET  OF  UNITS  [ SHORT_NAME ] 
SUBSET  OF  MISSION  [CODE] 
SUBSET  OF  UNITS  [SHORT_NAME] 
SUBSET  OF  MISSION  [CODE] 
SUBSET  OF  WEAPONS  [CODE] 
SUBSET  OF  WPNEXPED  [QUANTITY] 
SUBSET  OF  REASONS  [CODE] 
SUBSET  OF  UNITS  [SHORT_NAME] 
SUBSET  OF  MISSION  [CODE] 
SUBSET  OF  UNITS  [SHORT_NAME] 
SUBSET  OF  UNITS  [SHORT_NAME] 
SUBSET  OF  UNITS  [SHORT_NAME] 
SUBSET  OF  UNITS  [SHORT_NAME] 
SUBSET  OF  COMBATSYS  [CS] 
SUBSET  OF  REASONS  [CODE] 
SUBSET  OF  UNITS  [SHORT_NAME] 
SUBSET  OF  COMBATSYS  [CS] 
SUBSET  OF  COMBATSYS  [CS] 
SUBSET  OF  UNITS  [SHORT_NAME] 
SUBSET  OF  REASONS  [CODE] 
SUBSET  OF  UNITS  [ SHORT_NAME ] 
SUBSET  OF  COMBATSYS  [CS] 
SUBSET  OF  UNITS  [SHORT_NAME] 
SUBSET  OF  COMBATSYS  [CS] 
SUBSET  OF  REASONS  [CODE] 
SUBSET  OF  UNITS  [SHORT_NAME] 
SUBSET  OF  UNITS  [SHORT_NAME] 
SUBSET  OF  UNITS  [ SHORT_NAME ] 
SUBSET  OF  UNITS  [ SHORT_NAME J 
SUBSET  OF  UNITS  [SHORT_NAME] 
SUBSET  OF  UNITS  [ SHORT_NAME ] 
SUBSET  OF  TARGET  [ID] 
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SCDEC  [CATEGORY] 
SCDEC  [REASON] 
SCDUEIN  [UNIT] 
SCDUEIN  [CATEGORY] 
SCDUEOUT  [UNIT] 
SCDUEOUT  [CATEGORY] 
SCINC  [TARGET] 

SCINC  [CATEGORY] 
SCINC  [REASON] 
SCINDUMP  [TARGET] 
SCINDUMP  [CATEGORY] 
SCLOST  [UNIT] 

SCLOST  [CATEGORY] 
SCONHAND  [UNIT] 
SCONHAND  [CATEGORY] 
SCRECD  [UNIT] 

SCRECD  [CATEGORY] 
SCRECD  [REASON] 
SCSENT  [UNIT] 

SCSENT  [CATEGORY] 
SCSENT  [REASON] 
SCSHORT  [UNIT] 
SCSHORT  [CATEGORY] 
SCSHORT  [REASON] 
SCTRANS  [UNIT] 
SCTRANS  [REASON] 
TALIVE  [UNIT] 

TAVAIL  [UNIT] 

TGADA  [ID] 

TGCAPABLE  [ID] 
TGCAPABLE  [REASON] 
TGDETECT  [ID] 
TGDETECT  [REASON] 


SUBSET  OF  SUPPLIES  [CATEGORY] 
SUBSET  OF  REASONS  [CODE] 
SUBSET  OF  UNITS  [SHORT_NAME] 
SUBSET  OF  SUPPLIES  [CATEGORY] 
SUBSET  OF  UNITS  [SHORT_NAME] 
SUBSET  OF  SUPPLIES  [CATEGORY] 
SUBSET  OF  TARGETS  [ID] 

SUBSET  OF  SUPPLIES  [CATEGORY] 
SUBSET  OF  REASONS  [CODE] 
SUBSET  OF  TARGETS  [ID] 

SUBSET  OF  SUPPLIES  [CATEGORY] 
SUBSET  OF  UNITS  [SHORT_NAME] 
SUBSET  OF  SUPPLIES  [CATEGORY] 
SUBSET  OF  UNITS  [SHORT_NAME] 
SUBSET  OF  SUPPLIES  [CATEGORY] 
SUBSET  OF  UNITS  [SHORT_NAME] 
SUBSET  OF  SUPPLIES  [CATEGORY] 
SUBSET  OF  REASONS  [CODE] 
SUBSET  OF  UNITS  [SHORT_NAME] 
SUBSET  OF  SUPPLIES  [CATEGORY] 
SUBSET  OF  REASONS  [CODE] 
SUBSET  OF  UNITS  [ SHORT_NAME ] 
SUBSET  OF  SUPPLIES  [CATEGORY] 
SUBSET  OF  REASONS  [CODE] 
SUBSET  OF  UNITS  [SHORT_NAME] 
SUBSET  OF  REASONS  [CODE] 
SUBSET  OF  UNITS  [SHORT_NAME] 
SUBSET  OF  UNITS  [ SHORT_NAME ] 
SUBSET  OF  TARGETS  [ID] 

SUBSET  OF  TARGETS  [ID] 

SUBSET  OF  REASONS  [CODE] 
SUBSET  OF  TARGETS  [ID] 

SUBSET  OF  REASONS  [CODE] 
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TGRANGE  [ID] 

SUBSET 

OF 

TARGETS  [ID] 

TGSIDE  [ID] 

SUBSET 

OF 

TARGETS  [ID] 

TGSIZE  [ID] 

SUBSET 

OF 

TARGET 

S  [ID] 

TGUNIT  [ID] 

SUBSET 

OF 

TARGETS  [ID] 

TGUNIT  [UNIT] 

SUBSET 

OF 

UNITS 

[SHORT_ 

NAME] 

TRKILLED  [UNIT] 

SUBSET 

OF 

UNITS 

[SHORT_ 

NAME] 

UTADA  [UNIT] 

SUBSET 

OF 

UNITS 

[ SHORT_ 

NAME] 

UTAIRBASE  [UNIT] 

SUBSET 

OF 

UNITS 

[  SHORT_ 

NAME] 

UTAIRBASE  [AIRBASE] 

SUBSET 

OF 

UNITS 

[  SHORT_ 

NAME] 

UTAIRBASE  [REASON] 

SUBSET 

OF 

REASONS  [CODE] 

UTARRIVES  [UNIT] 

SUBSET 

OF 

UNITS 

[SHORT_ 

NAME] 

UTCAS  [UNIT] 

SUBSET 

OF 

UNITS 

[SHORT_ 

NAME] 

UTCA3  [SQUADRON] 

SUBSET 

OF 

UNITS 

[  SHORT_ 

NAME] 

UTCONTACT  [UNIT1] 

SUBSET 

OF 

UNITS 

[  SHORT_ 

NAME] 

UTCONTACT  [UNIT2 ] 

SUBSET 

OF 

UNITS 

[  SHORT_ 

NAME] 

UTDELAYED  [UNIT] 

SUBSET 

OF 

UNITS 

[SHORT 

_NAME] 

UTHQ  [UNIT] 

SUBSET 

OF 

UNITS 

[  SHORT_ 

NAME] 

UTHQ  [HQ] 

SUBSET 

OF 

UNITS 

[SHORT_ 

NAME] 

UTHQ  [REASON] 

SUBSET 

OF 

REASONS  [CODE] 

UTINCAR  [UNIT] 

SUBSET 

OF 

UNITS 

[SHORT_ 

NAME] 

UTINCAR  [INC] 

SUBSET 

OF 

UNITS 

[  SHORT_ 

NAME] 

UTLIFTED  [UNIT] 

SUBSET 

OF 

UNITS 

[SHORT_ 

NAME] 

UTLIFTED  [LIFTER] 

SUBSET 

OF 

UNITS 

[  SHORT_ 

NAME] 

UTPOSTURE  [UNIT] 

SUBSET 

OF 

UNITS 

[  SHORT_ 

NAME] 

UTPOSTURE  [REASON] 

SUBSET 

OF 

REASONS  [CODE] 

UTREINF  [UNIT] 

SUBSET 

OF 

UNITS 

[SHORT_ 

NAME] 

UTREINF  [RE INFORCER] 

SUBSET 

OF 

UNITS 

[SHORT_ 

NAME] 

UTSTART  [UNIT] 

SUBSET 

OF 

UNITS 

[  SHORT_ 

NAME] 

UTSTOP  [UNIT] 

SUBSET 

OF 

UNITS 

[  SHORT_ 

NAME] 

UTSTOP  [REASON] 

SUBSET 

OF 

REASONS  [CODE] 

UTSTRENGTH  [UNIT] 

SUBSET 

OF 

UNITS 

[  SHORT_ 

NAME] 

UTSUPPORT  [UNIT] 

SUBSET 

OF 

UNITS 

[SHORT_ 

_NAME  ] 

UTSUPPORT  [SUPPORT  UNIT] SUBSET 

OF 

UNITS 

[SHORT_ 

_NAME] 

i  ‘  iVl! 


INTERRELATION  CONTRAINTS 


UTSUPPORT  [REASON] 
UTTRANS  [UNIT] 
WPNEXPEND  [UNIT] 
WPNEXPEND  [MISSION] 
WPNEXPEND  [TYPE] 
WPNEXPED  [REASON] 


SUBSET  OF  REASONS  [CODE] 
SUBSET  OF  UNITS  [ SHORT_NAME ] 
SUBSET  OF  UNITS  [SHORT_NAME] 
SUBSET  OF  MISSIONS  [CODE] 
SUBSET  OF  WEAPONS  [TYPE] 
SUBSET  OF  REASONS  [CODE] 


A 

ft 

* 

i'. 


DOMAIN  NAME 
AIR  RADAR  RANGE 


CLASSIFICATION 


CODE  AIR  MISSION 


CODE  AIR  WEAPON 


CODE  COMBAT  SYS 


CODE  SUPPLY  CATEGORY 


CONFLICT 


EVENT 


INTERVAL 


LATITUDE 

LONGITUDE 

MEANING 


NAME  AIR  MISSION 


NAME  AIR  WEAPON 


NAME  COMBAT  SYSTEM 


NAME  DATA  BASE 


NAME  SUPPLY  CATEGORY 


DATA  DOMAINS 


FORMAT  &  MEANING 

Real  number  0.0  to  100000.  See 
Data  Requirements  Manual  pp. 

A“  37. 

CHAR (20)  Characters  "#".  and 
"&"  are  not  allowed.  Database 
security  classification. 

Positive  integer  less  than  17. 
See  Postprocessor  User  Guide 
table  C-19  pp.  C-13. 

Positive  integer  1  to  9999.  See 
Data  Requirements  Manual  pp. 
A-274 . 

Positive  integer  1  to  32767. 
(physical  limitation) . 

Positive  integer  2  to  32767 
(physical  limitation) .  See  Data 
Requirements  Manual  pp.  A-289. 

Value  is  "AIR. TO. AIR", 

"GROUND. TO. AIR",  or 
"WHILE . NOT . FLYING" . Identifies 
type  of  conflict  for  aircraft 
casualty . 

CHAR (15)  Characters  "#"  and 
are  not  allowed.  Identifies 
event  numbers  feeding  a  table. 

Positive  integer  1  to  32767. 
(physical  limitation) . 

Identifies  a  continuous  period 
of  game  play. 

Real  -90.0  to  90.0. 

REAL  -180.0  to  180.0. 

CHAR(IOO)  Characters  "#",  and 
are  not  allowed.  Meaning  of 
attribute,  or  contents  of  table. 

Values  contained  in 
Postprocessor  User  Guide  table 
C-19;  pp.  C-13. 

CHAR (20)  Characters  "#",  and  "&" 
are  not  allowed. 

CHAR (20)  Character  "#",  or  "&" 
are  not  allowed. 

CHAR(20)  Characters  "#",  and  "&" 
are  not  allowed. 

CHAR (20)  Characters  "#",  or 
are  not  allowed. 


i 


B 


NAME  TABLE 


CHAR (20)  Characters  "#",  and  "&" 
are  not  allowed. 


V.V.V.v.v'A 


DATA  DOMAINS 


DOMAIN  NAME  FORMAT  &  MEANING 

NAME  TARGET_SHORT  CHAR  (20) .  Characters  "#"  and 

are  not  allowed. 


NAME_TARGET_LONG 

NAME_TERM 

NAME_UNI T_SHORT 

NAME_UNIT_LONG 

NAVAL_MI SSI LE_RANGE 
NAVALUN I T_SP  EED 
ORDER_TYPE 
PERCENTAGE 

QUANTITY 


i 

REASON  AIRBASE 


CHAR(40).  Characters  "#"  and 
are  not  allowed. 

CHAR (20)  Characters  "f",  and 
are  not  allowed.  Attribute  or 
column  title  in  a  table. 

CHAR  (10) .  Characters  "#"  and 
are  not  allowed.  Names  of 
airbases,  ground  units,  naval 
units,  and  squadrons. 

CHAR (20) .  Characters  "#"  and  "  &  " 
are  not  allowed.  Names  of 
airbases,  ground  units,  naval 
units,  and  squadrons. 

Real  0.0  to  1.7E38  (physical 
limitation) .  See  Data 
Requirements  Manual  pp.  A-262. 

Real  0.001  to  1.7E38  (physical 
limitation) .  See  Data 
Requirements  Manual  pp.  A-452. 

CHAR (40)  Character  ,  or 
are  not  allowed.  Identifies  type 
of  order  given  by  player. 

Real  number  0.0  to  1.0. 
identifies  percentage  of  combat 
system  attnted,  combat  system 
killed, combat  system  lost, 
combat  system  on  hand,  combat 
system  received,  and  target 
capability. 

Positive  integer  0  to  32767 
(physical  limitation) . 

Identifies  the  number  of 
aircraft  in  unit,  aircraft 
killed,  aircraft  available 
available  for  launch,  aircraft 
aircraft  providing  close  air 
aircraft  remaining,  air  weapons 
fired,  cargo  trucks  killed, 
cargo  trucks  available  for 
convoy,  cargo  trucks  in  convoys, 
cargo  trucks  remaining,  HUMINT 
teams  available,  naval  missiles 
fired,  tanker  trucks  killed, 
tanker  trucks  available  for 
convoy,  tanker  trucks  in 
convoys,  and  tanker  trucks 
remaining . 

Positive  integer.  Identifies 
method  of  establishing  airbase. 


1 

91 


•miW 


DATA  DOMAINS 


DOMAIN  NAME 
REASON_AI RCRAF  T_K I LL 

REASON_CODE 

REASON_CS_LOST_CBT 

REASON_CS_LOST_NCBT 

REASON_CS_RECE I VED 

REASON_EXPEND 
REASON  HQ 


FORMAT  &  MEANING 


attrition . 


Positive  integer  O  to  107.  See 
Postprocessor  User  Guide  table 
C-27,  pp.  C-17. 

Positive  integer  of  value 
"6",  "8",  "10",  •’ll",  "42",  or  "50". 
Identifies  cause  of  a  combat 
system's  attrition  (combat). 


Positive  integer  of  value 
"24",  "25",  "40", "43",  or  "44". 
Identifies  caus$  of  a  combat 
system's  attrition  (non  combat). 


Positive  integer  of  value 
"36", "71",  or  "85".  Identifies 
reason  for  receipt  of  combat 
system. 


Positive  integer  of  value  "11", 
"15",  or  "50".  Identifies  reason 
for  air  weapon  expended. 


Positive  integer  of  value 
"0", "4"t "5", "51",  or  79". 
Identifier  method  of 
establishing  headquarters. 


REASON_NAME 
REASON_SUPPLY_DECR 
REASON_SUP P LY_I NCR 

REASON_SUP  P  LY_LOSS 

REASON  SUPPLY  RECD 


CHAR (40)  See  values 
Postprocessor  User  Guide  table 
C-27  pp.  C-17. 

Positive  integer  of  value  "12", 
"13"  or  "14".  Identifies  reason 
for  supply  category  decrease. 


Positive  integer  of  value 
"26", "27", "28"  or  "29". 
Identifies  reason  for  supply 
category  increase. 


Positive  integer  of  value 
"4"  "5", "16",  19", "26" . "27" . 
"28, "29"  "34", "37", "53", "59", 
"60",  or  "61".  Identifies  reason 
for  supply  category  lost. 

Positive  integer  of  value 
"1"  "4", "5". "16", "17"  "18", 

"19", "34", "37", "41", "53" 

"55", "59", "70", or  "87". 
Identifies  reason  supply 
category  received. 


REASON  SUPPLY  SENT 


Positive  integer  of  value 
"4"  "5", "16", "19", "2 6", "27" 
"28", "29", "34", "37", "53", "59", 


.  g1*  s'*  i' 
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DATA  DOMAINS 


DOMAIN  NAME 


REASON  SUPPLY  SHORT 


REASON  SUPPLY  TRANS 


REASON  TARGET  CAP 


REASON  TARGET  DET 


REASON  TRUCK  KILL 


REASON  UNIT  LIFT 


REASON  UNIT  POSTURE 


REASON  UNIT  STOP 


REASON  UNIT  SUPPORT 


REASON  UNIT  TRANS 


SIDE 


SIDES 


FORMAT  &  MEANING 

"50", "79", or  "92".  Identifies 
reason  supply  category  sent. 

Positive  integer  of  value 
"12", "13",  or  "14".  Identifies 
reason  for  supply  category 
shortage. 

Positive  integer  of  value 
"4", "5",  or  "62".  Identifies 
supply  category  means  of 
transportation . 

Positive  integer  of  value 
"0", "6", "7", "9", "26", "27", 

"28f,f  "29",  "36",  "46",  "51" 

"78"  "84",  "93",  or  f,107". 
Identifies  reason  for  change  in 
target  status. 

Positive  integer  of  value 
"6"  "33", "48", "70", "74",  "78", 
or  "93".  Identifies  source  of 
target's  detection. 


Positive  integer  of  value 

"ft"  m«  "9".  TrfanHfi 


Identifies 


cause  of  truck  attrition. 


Positive  integer  of  value 
"4", "5"  or  "62".  Identifies 
method  of  unit  lift. 

Positive  integer  of  value 
"3"  "4"  "5"  "11"  "30"  "31" 

" 3 2 " , " 4 6 " . "§0"  "6l", "$2"  "&2", 
"79",  "80", "82",  "84",  "86", 
"87"; "88"  or  "9i".  Identifies 
reason  for  change  in  unit 
posture. 

Positive  integer  of  value 
"4"  n5n  "30", "31", "32", "51", 

" 8 2 "  " 8 6 " ,  " 8 7 " ,  or  "95f’ . 
Identifies  reason  for  unit  stop. 

Positive  integer  of  value 
"0", "4 "("5", "47", "51"  or  "79". 
Identifies  reason  for  unit 
support . 

Positive  integer  of  value 
"4", "5",  or  "62" .  Identifies 
unit's  means  of  transportation. 

CHARM)  Value  is  "BLUE"  or 
"RED".  Identifies  unit  as 
friendly  or  hostile. 

CHAR (10)  Value  is  "BLUE", 
"NEUTRAL",  or  "RED."  Identifies 
targets  and  unit  delays  as 
friendly,  hostile,  or  neutral. 


m 


hr 


ms 


as 


DATA  DOMAINS 


DOMAIN  NAME 
STATUS 

SUPPLY_CATEGORY_LOST 
S  URF ACE_RAD AR_RAN G  E 

TARGET_CAPAB I L I T Y 

TARGET_CATEGORY 
TARGET_RANGE 

i 

TARGET_SIZE 

TIME 

UNIT_POSTURE 
UNIT_SUBTYPE 
UNIT_TYPE 
WEIGHT 


FORMAT  &  MEANING 


Integer  value  of  "0",  or  "l”. 
Identifies  status  of  day/night. 
Postprocessor.  ADA  of  a  target, 
ADA  of  an  unit,  unit  lift,  and 
unit  reinforcement. 

CHAR (20)  Value  is  "CONSUMED”, 
"ATTRITED",  or  "OTHER". 

Real  0.0  to  1.7E38  (physical 
limitation) .  See  Data 
Requirements  Manual  pp.  A-264. 

CHAR (20)  Value  is  "CREATED". 
"HIT",  ''KILLED",  or  "REPAIRED". 
Identifies  the  reason  for  a 
change  in  target  capability. 

CHAR (30)  See  values 
Postprocessor  User  Guide  table 
C-4l7  pp.  C-27. 

Real  0.0  to  1.7E38  (physical 
limitation) .  See  Data 
Requirements  Manual  pp.  A-412. 

Positive  integer  of  value  "1", 
"2",  or  "3".  Identifies  size  of 
target.  See  Postprocessor  User 
Guide  table  C-48,  p.  C-31. 

Real  number  0.0  to  365. 
Identifies  game  time  (in  decimal 
days)  . 

CHAR (20)  See  values 

Post-  processor  Users  Guide  table 

C-5 . .  pp.  C-36. 

CHAR  (20)  See  values 
Postprocessor  Users  Guide  table 
C-51  pp.  C-33 . 

CHAR  (20)  See  values 
Postprocessor  Users  Guide  table 
C-51  pp.  C-33. 

Real  number  0.0  to  1.7E38 
(physical  limitation) .  See  Data 
Requirements  Manual  pp.  A-373. 
Identifies  weight  for  supply 
category  or  transported 


ATTRIBUTE  DOMAIN 

ATTRIBUTE 
ACAVAIL . INTRVL 
ACAVAI L . T IME 
ACAVAIL. SIDE 
ACAVAIL. UNIT 
ACAVAI L . QUANT I T Y 
ACKILLED. INTRVL 
ACKILLED .TIME 
ACKILLED. SIDE 
ACKILLED. UNIT 
ACKILLED . CONFLICT 
ACKILLED . QUANTITY 
ACKILLED . L_MISSION 
ACKILLED . SHOOTER 
ACKILLED . S_MISSION 
ACKILLED . WPN_TYPE 
ACKILLED . NO_WPNS 
ACKILLED. REASON 
ACLAUNCH . INTRVL 
ACLAUNCH . TIME 
ACLAUNCH. SIDE 
ACLAUNCH. UN IT 
ACLAUNCH .MISSION 
ACLAUNCH . QUANTITY 
ACREM. INTRVL 
ACREM. TIME 
ACREM. SIDE 
ACREM. UNIT 
ACREM. QUANTITY 
CALI VE . INTRVL 
CALI VE. TIME 
CALIVE . SIDE 
CALIVE . UNIT 


CORRESPONDENCE 

DOMAIN 

INTERVAL 

TIME 

SIDE 

NAME_UN I T_SHORT 

QUANTITY 

INTERVAL 

TIME 

SIDE 

N AME_UN I T_S  HORT 

CONFLICT 

QUANTITY 

CODE_AI R_MI S  S I ON 
NAME_UN I T_S HORT 
CODE_AI R_MI S  S I ON 
CODE_AI R_WEAPON 
QUANTITY 

REASON_AIRCRAFT_KI LL 

INTERVAL 

TIME 

SIDE 

NAME_UN I T_S  HORT 

CODE_AI R_MI S  S I ON 

QUANTITY 

INTERVAL 

TIME 

SIDE 

N AME_UN I T_S HORT 

QUANTITY 

INTERVAL 

TIME 

SIDE 

NAME  UNIT  SHORT 


ATTRIBUTE  DOMAIN 

ATTRIBUTE 
CALIVE . QUANTITY 
CAVAIL . INTRVL 
CAVAIL . TIME 
CAVAIL. SIDE 
CAVAIL. UN IT 
CAVAIL. QUANTITY 
COMBATSYS . CODE 
COMBATS YS. SIDE 
COMBATSYS . CS 
CSATT . INTRVL 
CSATT . TIME 
CSATT. SIDE 
CSATT. UN IT 
CSATT . CS 
CSATT . REASON 
CSATT. QUANTITY 
CSKV. INTRVL 
CSKV. TIME 
CSKV. SIDE 
CSKV. UNIT 
CSKV. VICTIM 
CSKV. KILLER 
CSKV. QUANTITY 
CSLOST . INTRVL 
CSLOST . TIME 
CSLOST. SIDE 
CSLOST. UNIT 
CSLOST . CS 
CSLOST . REASON 
CSLOST. QUANTITY 
CSONHAND . INTRVL 
CSONHAND .TIME 


CORRESPONDENCE 

DOMAIN 

QUANTITY 

INTERVAL 

TIME 

SIDE 

NAME_UNI T_SHORT 
QUANTITY 
CODE_COMBAT_SYS 
SIDE 

NAME_COMBAT_SY  STEM 

INTERVAL 

TIME 

SIDE 

NAME_UN I T_S  HORT 

NAME_COMBAT_S Y  STEM 

REASON_CS_LOST_CBT 

PERCENTAGE 

INTERVAL 

TIME 

SIDE 

NAME_UN I T_S HORT 

NAME_COMBAT_S Y  STEM 

NAME_COMBAT_S Y  STEM 

PERCENTAGE 

INTERVAL 

TIME 

SIDE 

NAME_UN I T_S  HORT 

NAME_COMBAT_S Y  STEM 

REASON_CS_LOST_NCBT 

PERCENTAGE 

INTERVAL 

TIME 


TKwmnnrB 


ATTRIBUTE  DOMAIN  CORRESPONDENCE 


ATTRIBUTE 


CSONHAND . SIDE 


CSONHAND . UNIT 


CSONHAND . CS 


CSONHAND .QUANTITY 


CSRECD . INTRVL 


CSRECD . TIME 


CSRECD. SIDE 


CSRECD. UNIT 


CSRECD .CS 


CSRECD . REASON 


CSRECD. QUANTITY 


DATA  BASE. NAME 


DATA  BASE. CLASS 


D AYN I GHT. INTRVL 


DAYNIGHT . TIME 


DAYNI GHT. SUNUP 


DICTIONARY. TERM 


DICTIONARY. TABLE 


D I CT I ONARY . MEAN I NG 


DIRECTORY. TABLE 


DIRECTORY . CONTENTS 


DIRECTORY . EVENTS 


HUMINT . INTRVL 


HUMINT . TIME 


HUMINT. SIDE 


HUMINT. UNIT 


HUMINT. QUANTITY 


MISSIONS. CODE 


MISSIONS. MISSION 


MSLF I RED. INTRVL 


MSLFIRED . TIME 


MSLF I RED. SIDE 


DOMAIN 


SIDE 


NAME  UNIT  SHORT 


NAME  COMBAT  SYSTEM 


PERCENTAGE 


INTERVAL 


TIME 


SIDE 


NAME  UNIT  SHORT 


NAME  COMBAT  SYSTEM 


REASON  CS  RECIEVED 


PERCENTAGE 


NAME  DATA  BASE 


CLASSIFICATION 


INTERVAL 


TIME 


STATUS 


NAME  TERM 


NAME  TABLE 


MEANING 


NAME  TABLE 


MEANING 


EVENT 


INTERVAL 


TIME 


SIDE 


NAME  UNIT  SHORT 


QUANTITY 


CODE  AIR  MISSION 


NAME  AIR  MISSION 


INTERVAL 


TIME 


SIDE 


I 

I 


n 

M 


n 

m 
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ATTRIBUTE  DOMAIN  CORRESPONDENCE 


ATTRIBUTE 
MSLFIRED . UNIT 
MSLFIRED . QUANTITY 
NAVARRNG . INTRVL 
NAVARRNG . TIME 
NAVARRNG. SIDE 
NAVARRNG. UN IT 
NAVARRNG . AF_RNG 
NAVMSRNG . INTRL 
NAVMSRNG . TIME 
NAVMSRNG. SIDE 
NAVMSRNG. UN IT 
NAVMSRNG . MS_RNG 
NAVSPEED . INTRVL 
NAVSPEED . TIME 
NAVSPEED. SIDE 
NAVSPEED. UNIT 
NAVSPEED . SPEED 
NAVSRRNG . INTRVL 
NAVSRRNG . TIME 
NAVSRRNG. SIDE 
NAVSRRNG. UNIT 
NAVSRRNG . SR_RNG 
ORDERS . INTRVL 
ORDERS . TIME_SENT 
ORDERS. SIDE 
ORDERS . ORDER_TYPE 
ORDERS. UN IT 
ORDERS . TIME_SPEC 
PPSTATUS. INTRVL 
PPSTATUS . TIME 
PPSTATUS. STATUS 
REASONS . CODE 


DOMAIN 

NAME_UNIT_SHORT 

QUANTITY 

INTERVAL 

TIME 

SIDE 

NAME_UNIT_SHORT 

AI R_RADAR_RANGE 

INTERVAL 

TIME 

SIDE 

NAMEJUN I T_SHORT 

NAVAL_MS_RANGE 

INTERVAL 

TIME 


NAME_UN I T_SHORT 

NAVAL_UNIT_SPEED 

INTERVAL 

TIME 

SIDE 

NAME_UN I T_S  HORT 

SURF ACE_RAD AR_RANGE 

INTERVAL 

TIME 

SIDE 

ORDER_TYPE 
N AME_UN I T_S  HORT 
TIME 

INTERVAL 
TIME 
STATUS 
REASON  CODE 


$ 

w 
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ATTRIBUTE  DOMAIN  CORRESPONDENCE 


ATTRIBUTE 
REASONS . NAME 
SCDEC . INTRVL 
SCDEC . TIME 
SCDEC . TARGET 
SCDEC . CATEGORY 
SCDEC . REASON 
SCDEC. QUANTITY 
SCDUEIN. INTRVL 
SCDUEIN . TIME 
SCDUEIN. SIDE 
SCDUEIN. UNIT 
SCDUEIN. CATEGORY 
SCDUEIN. QUANTITY 
SCDUEOUT . INTRVL 
SCDUEOUT . TIME 
SCDUEOUT. SIDE 
SCDUEOUT. UNIT 
SCDUEOUT . CATEGORY 
SCDUEOUT . QUANTITY 
SCINC . INTRVL 
SCINC . TIME 
SCINC. SIDE 
SCINC . TARGET 
SCINC. CATEGORY 
SC INC. REASON 
SCINC. QUANTITY 
SCINDUMP . INTRVL 
SCINDUMP . TIME 
SCINDUMP. SIDE 
SCINDUMP . TARGET 
SCINDUMP . CATEGORY 
SCINDUMP . QUANTITY 


DOMAIN 
REAS  ON_N AME 
INTERVAL 
TIME 

N AME_T ARG  ET_SHORT 

NAME_SUP  P  LY_CATEGORY 

REASON_SUPPLY_DECR 

WEIGHT 

INTERVAL 

TIME 

SIDE 

NAME_UN I T_SHORT 

NAME_SUPPLY_CATEGORY 

WEIGHT 

INTERVAL 

TIME 

SIDE 

NAME_UNI T_SHORT 

NAME_SUP  P  LY_CATE  GORY 

WEIGHT 

INTERVAL 

TIME 

SIDE 

N AME_TARGE  T_S  HORT 

NAME_SUPPLY_CATEGORY 

REASON_SUPPLY_INCR 

WEIGHT 

INTERVAL 

TIME 

SIDE 

NAME_TARGET_SHORT 
NAME_SUP P  LY_CATEGORY 
WEIGHT 
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ATTRIBUTE  DOMAIN  CORRESPONDENCE 


ATTRIBUTE 
SCLOST . INTRVL 
SCLOST . TIME 
SCLOST. SIDE 
SCLOST. UNIT 
SCLOST . CATEGORY 
SCLOST . REASON 
SCLOST. QUANTITY 
SCLOST .ACTION 
SCONHAND . INTRVL 
SCONHAND . TIME 
SCONHAND. SIDE 
SCONHAND . UNIT 
SCONHAND . CATEGORY 
SCONHAND . QUANTITY 
SCRECD . INTRVL 
SCRECD . TIME 
SCRECD . SIDE 
SCRECD. UNIT 
SCRECD . CATEGORY 
SCRECD . REASON 
SCRECD. QUANTITY 
SCSENT . INTRVL 
SCSENT . TIME 
SCSENT. SIDE 
SCSENT. UNIT 
SCSENT . CATEGORY 
SCSENT . REASON 
SCSENT. QUANTITY 
SCSHORT . INTRVL 
SCSHORT . TIME 
SCSHORT. SIDE 
SCSHORT. UNIT 


DOMAIN 

INTERVAL 

TIME 

SIDE 

NAME_UN I T_S  HORT 
NAME_SUPPLY_CATEGORY 
REASON_SUP  P  LY_LOST 
WEIGHT 

S  UP  P  LY__CATE  GORY_LOST 

INTERVAL 

TIME 

SIDE 

N AME_UN I T_S  HORT 

NAME_SUPPLY_CATEGORY 

WEIGHT 

INTERVAL 

TIME 

SIDE 

NAME_UN I T_S HORT 

NAME_SUP P LY_CATEGORY 

REASON_SUPPLY_RECD 

WEIGHT 

INTERVAL 

TIME 

SIDE 

NAME_UNI T_SHORT 

NAME_S  UP  P  LY_CATE  GORY 

REASON_SUPPLY_SENT 

WEIGHT 

INTERVAL 

TIME 

SIDE 

NAME  UNIT  SHORT 


SYUWWV 


ATTRIBUTE  DOMAIN  CORRESPONDENCE 


ATTRIBUTE 
SCSHORT . CATEGORY 
SCSHORT . REASON 
SCSHORT . QUANTITY 
SCTRANS . INTRVL 
SCTRANS . TIME 
SCTRANS. SIDE 
SCTRANS. UNIT 
SCTRANS . REASON 
SCTRANS . DRY_WT 
SCTRANS . WET_WT 
SUPPLIES. CODE 
SUPPLIES. SIDE 
SUPPLIES . CATEGORY 
TALIVE . INTRVL 
TALIVE . TIME 
TALIVE. SIDE 
TALIVE. UNIT 
TALIVE. QUANTITY 
TARGETS . INTRVL 
TARGETS . TIME 
TARGETS. ID 
TARGETS . NAME 
TARGETS . CATEGORY 
TAVAIL . INTRVL 
TAVAIL . TIME 
TAVAIL. SIDE 
TAVAIL. UNIT 
TAVAIL. QUANTITY 
TGADA. INTRVL 
TGADA. TIME 
TGADA. ID 
TGADA. STATUS 


DOMAIN 

NAME_SUPPLY_CATEGORY 

REASON_SUPPLY_SHORT 

WEIGHT 

INTERVAL 

TIME 

SIDE 

NAME_UNIT_SHORT 
RE ASON_SUP  P  LY_TRANS 
WEIGHT 
WEIGHT 

CODE_SUPPLY_CATEGORY 

SIDE 

NAME_S  UP  P  L Y_CATE  GORY 
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ATTRIBUTE  DOMAIN  CORRESPONDENCE 


ATTRIBUTE 
TGCAPABLE . INTRVL 
TGCAPABLE . TIME 
TGCAPABLE. ID 
TGCAPABLE .ACTION 
TGCAPABLE . REASON 
TGCAPABLE . PCT_CAPABLE 
TGDETECT . INTRVL 
TGDETECT . TIME 
TGDETECT. ID 
TGDETECT. SIDE 
TGDETECT . REASON 
TGRANGE . INTRVL 
TGRANGE . TIME 
TGRANGE . ID 
TGRANGE . RNG 
TGS IDE. INTRVL 
TGSIDE . TIME 
TGSIDE . ID 
TGSIDE. SIDE 
TGSIZE. INTRVL 
TGSIZE .TIME 
TGSIZE. ID 
TGSIZE. SIZE 
TGUN IT. INTRVL 
TGUNIT . TIME 
TGUNIT . ID 
TGUNIT. UNIT 
TGUNIT . LAT 
TGUNIT. LON 
TRKILLED. INTRVL 
TRKILLED . TIME 
TRKILLED. SIDE 


DOMAIN 

INTERVAL 

TIME 

NAME_TARGET_SHORT 

TARGET_CAP ABILITY 

REASON_TARGET__CAP 

PERCENTAGE 

INTERVAL 

TIME 

N AME_TARGE  T_S  HORT 
SIDES 

REASON_TARGET_DET 

INTERVAL 

TIME 

NAME_TARGET_SHORT 

TARGET_RANGE 

INTERVAL 

TIME 

NAME_TARGET_SHORT 

SIDES 
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TIME 

NAME_TARGET_SHORT 
TARGET_S I Z  E 
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NAME_TARGET_SHORT 

N AME_UN I T_S  HORT 

LATITUDE 
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TIME 

SIDE 
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ATTRIBUTE  DOMAIN  CORRESPONDENCE 


ATTRIBUTE 
TRKILLED . UNIT 
TRKILLED .CARGOS 
TRKILLED. TANKERS 
TRKILLED. REASON 
UNITS . SHORT_NAME 
UNITS . LONG_NAME 
UNITS. TYPE 
UNITS . SUBTYPE 
UNITS. SIDE 
UNITS. AIRCRAFT 
UTADA . INTRVL 
UTADA. TIME 
UTADA. SIDE 
UTADA. UNIT 
UTADA. STATUS 
UTAIRBASE . INTRVL 
UTAIRBASE . TIME 
UTAIRBASE. SIDE 
UTAIRBASE. UNIT 
UTAIRBASE .AIRBASE 
UTAIRBASE . REASON 
UTARRIVES . INTRVL 
UTARRIVES . TIME 
UTARRIVES. SIDE 
UTARRIVES . UNIT 
UTARRIVES . LAT 
UTARRIVES .  LON 
UTCAS. INTRVL 
UTCAS . TIME 
UTCAS. SIDE 
UTCAS. UN IT 
UTCAS . SQUADRON 


DOMAIN 

NAME_UNIT_SHORT 

QUANTITY 
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NAME_UN I T_S  HORT 

NAME_UNIT_LONG 
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QUANTITY 
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SIDE 

NAME_UN I T_S HORT 

STATUS 
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TIME 

SIDE 

NAME_UN I T_S HORT 

NAPffi_UN I T_S HORT 

REASON_AI RBASE 

INTERVAL 

TIME 

SIDE 

NAME_UNIT_SHORT 

LATITUDE 

LONGITUDE 

INTERVAL 

TIME 

SIDE 

NAME_UNI T_SHORT 
NAME  UNIT  SHORT 
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ATTRIBUTE  DOMAIN  CORRESPONDENCE 


ATTRIBUTE 
UTCAS . NO_AIRCRAFT 
UTCONTACT . INTRVL 
UTCONTACT . TIME 
UTCONTACT. UNI T1 
UTCONTACT . UNIT2 
UTCONTACT . STATUS 
UTCONTACT . POSTURE 1 
UTCONTACT . POSTURE2 
UTDELAYED . INTRVL 
UTDELAYED . TIME 
UTDELAYED. SIDE 
UTDELAYED. UNIT 
UTDELAYED . DELAYER_SIDE 
UTDELAYED . LAT 
UTDELAYED . LON 
UTDELAYED . DURATION 
UTHQ . INTRVL 
UTHQ.TIME 
UTHQ. SIDE 
UTHQ .UNIT 
UTHQ . HQ 
UTHQ . REASON 
UT INCAR. INTRVL 
UTINCAR . TIME 
UTINCAR. SIDE 
UTINCAR. UNIT 
UTINCAR. INC 
UTLIFTED . INTRVL 
UTLIFTED .TIME 
UTLIFTED. SIDE 
UTLIFTED. UNIT 
UTLIFTED. LIFTER 
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N AME_UN I T_S HORT 
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SIDE 
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LATITUDE 
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SIDE 
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NAME_UNIT_SHORT 

REASON_HQ 
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TIME 

SIDE 

NAME_UN I T_S HORT 

NAME_UN I T_SHORT 
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NAME_UN I T_S  HORT 
NAME  UNIT  SHORT 
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ATTRIBUTE  DOMAIN  CORRESPONDENCE 


ATTRIBUTE 
UTLIFTED. STATUS 
UTLIFTED. REASON 
UTPOSTURE . INTRVL 
UTPOSTURE . TIME 
UTPOSTURE .SIDE 
UTPOSTURE. UNIT 
UTPOSTURE . NEW_POSTURE 
UTPOSTURE . OLD_POSTURE 
UTPOSTURE . REASON 
UTPOSTURE . LAT 
UTPOSTURE . LON 
UTREINF . INTRVL 
UTREINF . TIME 
UTREINF. SIDE 
UTREINF. UNIT 
UTREINF . RE INFORCER 
UTREINF . STATUS 
UTSTART . INTRVL 
UTSTART . TIME 
UTSTART. SIDE 
UTSTART. UNIT 
UTSTART . LAT 
UTSTART . LON 
UTSTART . DEST_LAT 
UTSTART . DEST_LON 
UTSTOP . INTRVL 
UTSTOP . TIME 
UTSTOP. SIDE 
UTSTOP. UNIT 
UTSTOP . LAT 
UTSTOP . LON 
UTSTOP . REASON 
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REASON_UNIT_LIFT 
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NAME_UN I T_SHORT 
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TIME 

SIDE 

NAME_UN I T_SHORT 

NAME_UN I T_SHORT 

STATUS 
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TIME 

SIDE 

NAME_UN I T_S HORT 

LATITUDE 

LONGITUDE 

LATITUDE 

LONGITUDE 

INTERVAL 

TIME 

SIDE 

N AME_UN I T_S HORT 
LATITUDE 
LONGITUDE 
REASON  UNIT  STOP 


ATTRIBUTE  DOMAIN  CORRESPONDENCE 


ATTRIBUTE 
UTSTRENGTH . INTRVL 
UTSTRENGTH . TIME 
UTSTRENGTH. SIDE 
UTSTRENGTH. UNIT 
UTSTRENGTH . STRENGTH 
UTSUPPORT . INTRVL 
UTSUPPORT . TIME 
UTSUPPORT. SIDE 
UTSUPPORT. UNIT 
UTSUPPORT . SUPPORT_UNIT 
UTSUPPORT . REASON 
UTTRANS . INTRVL 
UTTRANS . TIME 
UTTRANS. SIDE 
UTTRANS. UNIT 
UTTRANS . DRYJWT 
UTTRANS . WET_WT 
UTTRANS . REASON 
WEAPONS . CODE 
WEAPONS . TYPE 
WEAPONS. SIDE 
WPNEXPEND . INTRVL 
WPNEXPEND . TIME 
WPNEXPEND. SIDE 
WPNEXPEND. UNIT 
WPNEXPEND .MISSION 
WPNEXPEND . QUANTITY 
WPNEXPEND . TYPE 
WPNEXPED . REASON 
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